NSDocument not displaying save prompt on dirty document

2016-05-23 Thread livinginlosangeles 
I have an NSDocument subclass that is no longer displaying a save prompt when I 
close a dirty document using the close: IBAction. My document is marked as 
dirty and I am using the NSDocument’s NSUndoManager. I am not doing anything 
behind the document’s back by setting the update count, etc. Would anyone have 
an explanation as to why my prompt has disappeared?

Thanks,

Patrick
___

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

Please do not post 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: NSAlert and threading

2016-05-23 Thread Jens Alfke 

> On May 23, 2016, at 2:41 PM, Fritz Anderson  wrote:
> 
> Hence the rule that you don’t do _anything_ lengthy on the main (GUI-runloop) 
> thread. You can see how using a separate thread would solve your problem. 
> Welcome to 2003. 

Less dogmatically, you can use -performSelector:withObject:afterDelay:, with a 
zero delay, to schedule the actual work to take place right after the alert 
finishes handling the event and closing.

—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: All threads in app periodically blocked

2016-05-23 Thread pscott 

On 5/23/2016 1:56 PM, Fritz Anderson wrote:

On 23 May 2016, at 1:37 PM, Seth Willits  wrote:

I'm telling you guys I used every skill I could think of, staring at zillions of 
system calls in traces etc, and in the end all I needed was a little luck and it 
was all due to a simple copy & paste error.

and Seth was enlightened.

— F


You're not alone. Even something as simple as editing a makefile can 
drive you mad when bitten by the insidious copy & paste error.


http://skycoast.us/pscott/archives/71.html

 - P



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: NSAlert and threading

2016-05-23 Thread Fritz Anderson 
On 23 May 2016, at 4:14 PM, Tom Doan  wrote:
> 
> I have an menu operation which, before it fully executes, pops up 
> an NSAlert asking a Yes/No question ("Selection Only(Y/N)?") then, 
> depending upon the answer will either apply to the whole list or just 
> the selection. However, no matter what I do (other than putting the 
> operation in a separate thread), the alert box stays on the screen 
> until the operation is done. release doesn't work. orderout on the 
> window doesn't work. Is there any way to do this (other than 
> changing the threading) so the alert box goes away when I'm done 
> with it?

Do I understand correctly that you perform this lengthy operation in direct 
response to the button click in the alert? If so, this is the expected behavior.

{ F : F ∈ any modern framework } works from a run loop. At each pass in the 
loop, the framework looks for the next event to handle (e.g. a click, or the 
need to close a window). After interpreting it (for instance as a button 
click), it calls the appropriate handler, sometimes in your code (such as the 
callback for the alert buttons), sometimes other parts of the framework (such 
as the part that removes a window from the display list).

If your handler immediately executes a lengthy operation without returning to 
the runloop, then the “close the alert” event won’t come up until the lengthy 
operation concludes and your handler returns control to the runloop. Then the 
loop finds the close-alert event, and takes care of it.

Hence the rule that you don’t do _anything_ lengthy on the main (GUI-runloop) 
thread. You can see how using a separate thread would solve your problem. 
Welcome to 2003. 

Apple has gone to great lengths to make threading easy (from the sound of it, 
your case isn’t all that bad), but it can’t hide it from you entirely.

— F


___

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

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

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

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

NSAlert and threading

2016-05-23 Thread Tom Doan 
I have an menu operation which, before it fully executes, pops up 
an NSAlert asking a Yes/No question ("Selection Only(Y/N)?") then, 
depending upon the answer will either apply to the whole list or just 
the selection. However, no matter what I do (other than putting the 
operation in a separate thread), the alert box stays on the screen 
until the operation is done. release doesn't work. orderout on the 
window doesn't work. Is there any way to do this (other than 
changing the threading) so the alert box goes away when I'm done 
with it?

Best regards,

Tom Doan
Estima
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

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

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

2016-05-23 Thread Quincey Morris 
On May 23, 2016, at 11:16 , Raimond Hettrich  wrote:
> 
> I have the following problem with the constellation 
> coreData-treeController-outlineView.

Well, you keep asking, and you keep getting no answer, because no one on this 
list knows the answer — the problem domain is too large even to guess where to 
look.

My intuition says the problem is unwanted duplication. Somewhere within the 
complex of components (Core Data, KVO, NS…Controller, table view plus whatever 
else) there is a pair of duplicate objects, which means your data model isn’t 
actually connected to the user interface presented to the user. This sometimes 
happens to developers who are new to Cocoa because it’s not always obvious 
whether objects are created programmatically (via code) or archivally (via IB 
design).

I think your next step is to try to make your problem smaller. (It might help 
to work in a copy of your project, if your debugging changes are destructive.) 
Try adding objects to your managed object context via code, and see whether 
those changes are saved.

___

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

Please do not post 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: All threads in app periodically blocked

2016-05-23 Thread Seth Willits 
Holy cow!! 

I figured out why process was halting every 150 ms.


I happened to find the critical clue by chance today. I was trying Ken's 
suggestion of explicitly using NSActivity to avoid any potential app napping 
(which wasn't what was happening), and for only then did the application 
suddenly stop half way through the data processing and claim it couldn't 
allocate anything Weird. 樂

Because this CVPixelBufferPool wouldn't allocate anymore pixel buffers, I 
figured there must be a leak somewhere, so I profiled with Instruments for the 
20th time, but yet the Allocations were pretty constant and low, and there were 
no leaks... Weird. 

So then out of habit, I printed out the CVPixelBufferPool in the debugger and 
*luckily* (since there's no public API for this), the pool's description showed 
"inUse=3768".  There should be like 20 max. And if there are 3768 PBs, then 
surely I should see that in Instruments! … Weird.

It quickly occurred to me that the CVPixelBuffers are actually 
IOSurface-backed, not normal malloced-memory backed, so then I Snapshotted the 
VM address space a bazillion times and sure enough that was every increasing up 
to like 20 GB , and all of that growth was in IOKit. So yep, it's these 
IOSurfaces which are allocated by the system, not by my app, which is why they 
didn't show up in the normal Allocations track, and because they're in a pool, 
there actually is no leak. But how does changing my operation from sync to 
"async" (yet, using the exact same "work" code) make these IOSurfaces stack up? 
... Weird. 樂

My thought at this point was maybe it was some autorelease pool nonsense. These 
pixel buffers do get inserted into autorelease pools at various points, so I 
figured maybe there was a pool draining difference because I've been bitten by 
that before with GCD in past OS versions. So I plastered @autorelease{...} all 
over the place to see if it had any effect. It didn't. 

So then I figured, the ONLY other logical explanation is that this NSOperation 
*itself* isn't being deallocated, since it keeps a reference (chain) to this 
CVPixelBuffer, so if the NSOp doesn't deallocate, then the PB doesn't get 
returned to the pool. So I stuck I breakpoint in -dealloc and sure enough, the 
operation doesn't deallocated until *waay* later. Multiple seconds after it 
and several thousand other operations are done too. *Weird* 

Interestingly, the stack frame that triggered the deallocation of this 
NSOperation was KVO related. That seemed a bit odd to me, but got me thinking 
that the only real difference between a synchronous NSOp and async NSOp is the 
KVO notifications that need to be fired, so I opened up the code again to look 
at that and BOOM. I saw a bug. The very first thing I did was:

- (void)start
{
[self willChangeValueForKey:@"isExecuting"];
...
[self willChangeValueForKey:@"isExecuting"];


I had mistakenly (thanks to copy & paste ) called willChange twice and not 
called didChange. As soon as I fixed that, everything was working fine. The 
operation was properly deallocated, the PBs were properly returned to the pool, 
and the IOSurfaces properly released. 




I'm not sure of the details, but as far as I can tell, the system periodically 
halted my entire process while it scrambled to keep up with my insane demands 
of constantly allocating gigabytes of IOSurfaces.

I'm telling you guys I used every skill I could think of, staring at zillions 
of system calls in traces etc, and in the end all I needed was a little luck 
and it was all due to a simple copy & paste error.

Sigh.


Thanks,

--
Seth Willits



> On May 22, 2016, at 10:48 AM, Seth Willits  wrote:
> 
> I'm thoroughly confused and increasingly desperate. *All* of the threads in 
> my application periodically are blocked for 30-50 ms pretty regularly, about 
> every 150 ms.
> 
> I'm processing a bunch of data via NSOperations running in a couple of 
> "serial" (maxConcurrentOperationCount = 1) NSOperationQueues. Each of the 
> operations is itself synchronous (overriding -main). Everything works as 
> expected. For performance reasons, I want to move one of the operation types 
> to being asynchronous and eventually allow two concurrent operations.
> 
> So to start with, I took the synchronous code in -main, moved it into -start, 
> and added the appropriate KVO notifications for isExecuting, isFinished, and 
> implemented the right accessors etc. So effectively the operation says it's 
> asynchronous, but all of its work is actually done in -start, followed by 
> notifying it's finished. The work is all done correctly, but I noticed it 
> took significantly longer to complete. 
> 
> Thankfully I have a nifty bit of debugging code which tracks the start and 
> ends of each of these operations and visualizes them, and this is what I 
> noticed:
> http://www.sethwillits.com/temp/upshot/upshot_yJutoKqY.png
> 
> At very regular intervals

Core Data, OutlineView, TreeController

2016-05-23 Thread Raimond Hettrich 
Hallo all,

I´m new in objective-c coding and I have the following problem with the 
constellation coreData-treeController-outlineView.

I’ve got an view based outlineView which shows an hierarchical tree. I can add 
a new row with the default values of my entities attributes. I can add new 
children's depended of which row is selected and I can delete the selected row.

This shows that the bindings coreData-entity -> 
treeController-managedObjectContext -> tableViewColumn-arrangedObjects -> 
tableViewCell-objectValue.name are correct an functional.

Also I can use the saveAction, which was automatically implemented by creating 
the new coreDataProject, but if I close and reopen the app my outlineView shows 
nothing. 

This is what the following logs return. 

BOOL savedOK = [[self managedObjectContext] save:];   -> 1
NSLog(@"has Changes %hhd", _managedObjectContext.hasChanges);   -> 0

Is there a need to add code to the saveAction? I know that in the constallation 
coreData-arrayController-tableView is no need to add extra code. Since weeks 
I’m looking for an answer and I can’t find it.  

Have anyone an idea, what’s going wrong?

Many thanks,
Raycord

___

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

Please do not post 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: All threads in app periodically blocked

2016-05-23 Thread Seth Willits 
> On May 22, 2016, at 12:44 PM, Quincey Morris 
>  wrote:
> 
> On May 22, 2016, at 10:48 , Seth Willits  wrote:
>> 
>> Can anyone think of what I should look for to figure out *why* they're 
>> blocked?
> 
> Do these operations go on long enough that you can see the usage stabilize in 
> Activity Monitor? If so, what are the user and system percentages of CPU 
> while it’s running?

The whole process goes on for a long time. CPU usage is like 5-10% system, 
10-15% user. These delays are periodic throughout the entire process. 



> On a different front, is it necessary that you use NSOperations? Can you 
> switch to plain GCD instead?

I just switched from GCD. The operations do make it simpler to manage in this 
case as I'm leverage dependencies across various queues and avoiding the need 
for multiple semaphores as before.



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