Re: NSThread to NSOperation and blockUntil

[Quincey Morris]

On Mar 21, 2016, at 18:07 , Trygve Inda  wrote:
> 
> I would like to move this to NSOperation and NSOperationQueue but I see no
> way to replicate this behavior.

I think the GCD/NSOperationQueue concept of “background” quality of service is 
what you want here. That would let your re-factored calculations run at full 
speed during system idle times, using multiple CPUs, until CPU resources were 
needed for something of higher quality service. At that time, your background 
calculation would be throttled back until the system goes idle again.
___

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: #selector noob question

[Quincey Morris]

On Mar 21, 2016, at 20:27 , Eric E. Dolecki  wrote:
> 
> Quick question. If I use #selector(funcName) - does it always send an
> argument of the obj if the func requests it or not?
> 
> If the function being called has a typed argument of something like
> sender:UIButton, I can reference the sender in the func. Before with a
> string we could add the ":" to inform that it would be supplied. Now is it
> implied that it will be supplied?

1. The “:” was never optional, in the sense that you could choose whether or 
not to “add” it. Obj-C @selector(funcName) and @selector(funcName:) — 
“funcName” and “funcName:” in the previous Swift — are completely unrelated 
selectors. When performing the first of these selectors, there was never a 
parameter, and when performing the second there was always a parameter.

2. Selectors don’t send messages, selectors *are* messages. They are, 
approximately, polymorphic (class-independent) method names known to the 
runtime.

When performing a selector, it has always been necessary to supply the correct 
number of arguments. It was an implementation detail of the Obj-C runtime that 
omitting or oversupplying parameters would not necessarily crash, and this fact 
could be exploited sometimes.

3. The new #selector syntax specifies the method by qualified name (via an 
expression that isn’t evaluated). For example:

> import Cocoa
> 
> let x1 = #selector (NSView.addSubview(_:))
> 
> let v: NSView
> let x2 = #selector (v.addSubview(_:))
> 
> class A: NSView
> {
>   let x3 = #selector (addSubview(_:))
> }


These 3 declarations specify the single-parameter addSubview method explicitly, 
by specifying the parameter keyword (_). They differ in the way they tell the 
compiler which class to consult to determine whether/how ‘addSubview:’ is 
declared.

But Swift has additional source code forms. If it’s unambiguous which method is 
meant, you can just use the method name without keywords:

> class A: NSView
> {
>   let x4 = #selector (isDescendantOf) // OK because there is only one 
> matching method
>   let x5 = #selector (addSubview) // ambiguous
> }


and you can use ‘as’ to specify the type of function, to distinguish between 
overloaded functions that have the same name and parameter keywords, but 
different parameter or return types.

Note that x4 corresponds to Obj-C @selector(isDescendantOf:), not 
@selector(isDescendantOf).

4. Swift selectors are still polymorphic, so they aren’t tied to a class at 
runtime. For example, x1 above doesn’t mean “the selector for ‘addSubview:’ in 
class NSView". It means “the selector for method addSubview:, using NSView’s 
addSubview: method as a pattern to resolve any ambiguities”. You can still 
perform such a selector on any class that has a matching method, just like in 
Obj-C.

5. The problem being solved here is that in Obj-C the compiler can’t check that 
a selector is valid. There are two parts to this:

a. It can only check that a method exists for a selector if a header file 
declaring that method is #imported into the current compilation.

b. It cannot check the return type safely under any circumstances, leading to 
crashes when methods exist with the same selector but different return types.

Swift solves the problem by requiring you to be explicit about which function 
signature the selector represents.

___

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

#selector noob question

[Eric E. Dolecki]

Quick question. If I use #selector(funcName) - does it always send an
argument of the obj if the func requests it or not?

If the function being called has a typed argument of something like
sender:UIButton, I can reference the sender in the func. Before with a
string we could add the ":" to inform that it would be supplied. Now is it
implied that it will be supplied?

Thanks if this seems like a silly question - just reading about 2.2 now.

Eric
___

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

NSThread to NSOperation and blockUntil

[Trygve Inda]

I have a thread that is invoked with:

[NSThread detachNewThreadSelector:@selector(threadMethod:) toTarget:self
withObject:self];

It uses NSConditionLock and works well.

This thread performs a complex process but does it slowly so as to not use
much processor time. I specify how long I want it to take (1 to 30 minutes)
and use:

//  block this task until time has elapsed or an exit signal is received.
if ([[self lock] lockWhenCondition:kConditionThreadMustExit beforeDate:[self
blockUntil]])  
 [[self lock] unlock];

blockUntil simply checks to see how much work has been done vs how much time
has passed and if 50% of the work has been done, blocks until 50% of the
time has passed. It works well since the work is very linear.

I would like to move this to NSOperation and NSOperationQueue but I see no
way to replicate this behavior. My current thread is limited to a single
processor core and with NSOperation I could split it to multiple cores, but
in so doing I seem to lose this "delay for a while" bit.

Any ideas?

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: UIDocument with NSFileWrapper

[Luther Baker]

Thanks for posting this. Exploring UIDocument and caching/parsing JSON
instead of CoreData for a service based mobile app that must support
offline mode ... and looking forward to considering where you landed.
On Mon, Mar 21, 2016 at 5:11 PM  wrote:

>
> > On Mar 21, 2016, at 2:08 AM, Quincey Morris <
> quinceymor...@rivergatesoftware.com> wrote:
> >
> > On Mar 19, 2016, at 18:54 , davel...@mac.com wrote:
> >>
> >> What I’m having trouble understanding is how I store the images (whose
> filenames will vary from document to document) with NSFileWrapper. In my
> top level directory do I have my main model file as a JSON file along with
> a file (JSON or plist) that lists all the images and then have an Image
> directory that another NSFileWrapper is used to read/write the images (that
> are stored in the Image subdirectory)?
> >>
> >> Or can I simply store all the files without a subdirectory? I still
> suspect I need to have a file with a fixed name (such as image.plist) that
> tells me what all the other filenames are to put in the NSFileWrapper (vs.
> using NSFileManager to ask for the name of all the files).
> >
> > There’s no correct answer to these questions. It’s a design problem
> whose answer is whatever works best in your use case. I’d recommend you
> start by choosing what looks to you like the most straightforward approach,
> then be prepared to revise your strategy later if it doesn’t work out well.
> (The amount of code relating to file wrappers is likely to be small
> relative to the code that generally maintains your data model, so rewriting
> it shouldn’t be onerous. However, that suggests it would be prudent not to
> let the wrappers propagate too deeply into the model. Keep them as an
> artifact of the save mechanism in particular, rather than the data model in
> general.)
> >
>
> Ok, thanks again for all your feedback. I took a stab at implementing it
> yesterday. Everything is in my subclass of UIDocument. The rest of the
> model is a layer below the UIDocument subclass (i.e., the subclass has a
> couple instance variables which are the main model) although I did put a
> few methods in the UIDocument class to add the images since that needs to
> change the NSFileWrapper.
>
> I think I've got it working. Here is how I did it (in case this helps
> anyone else and in case anyone else sees a problem with this).
>
> UIDocument subclass has a NSFIleWrapper instances for each of these:
>
> 1. Top level NSFileWrapper directory wrapper.
> 2. It contains a directory wrapper for a subdirectory named Images where
> all the image files (that won't be updated often go). I put the method to
> add an image here so that it could update the NSFileWrapper
> 3. a NSFileWrapper that contains a single file that is a list of all the
> image filenames that is added to the top level NSFileWrapper
> 4. a NSFileWrapper for the rest of the model that will change often and is
> added to the top level NSFileWrapper
>
> Whenever an image is added, I remove the NSFileWrapper in #3 from the top
> level file wrapper, created a new NSFileWrapper with the new list of
> images, and then add that to the top level NSFileWrapper. And add the image
> file to the NSFileWrapper in #2. It appears you must call removeFileWrapper
> on the top level NSFileWrapper and then add the new NSFileWrapper with
> addFileWrapper rather than just calling addFileWrapper with the same
> preferred filename and replacement NSFileWrapper. Similarly with my #4 main
> data model file, I call removeFileWrapper and addFileWrapper each time a
> save occurs since this data changes frequently.
>
> Since images won't be added as often as the rest of the model is updated,
> I'm hoping this won't cause these images to be re-written every time a save
> is performed but I'm not certain how to verify this is the case.
>
> Thanks,
> Dave Reed
> ___
>
> 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/lutherbaker%40gmail.com
>
> This email sent to lutherba...@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: UIDocument with NSFileWrapper

[davelist]

> On Mar 21, 2016, at 2:08 AM, Quincey Morris 
>  wrote:
> 
> On Mar 19, 2016, at 18:54 , davel...@mac.com wrote:
>> 
>> What I’m having trouble understanding is how I store the images (whose 
>> filenames will vary from document to document) with NSFileWrapper. In my top 
>> level directory do I have my main model file as a JSON file along with a 
>> file (JSON or plist) that lists all the images and then have an Image 
>> directory that another NSFileWrapper is used to read/write the images (that 
>> are stored in the Image subdirectory)?
>> 
>> Or can I simply store all the files without a subdirectory? I still suspect 
>> I need to have a file with a fixed name (such as image.plist) that tells me 
>> what all the other filenames are to put in the NSFileWrapper (vs. using 
>> NSFileManager to ask for the name of all the files).
> 
> There’s no correct answer to these questions. It’s a design problem whose 
> answer is whatever works best in your use case. I’d recommend you start by 
> choosing what looks to you like the most straightforward approach, then be 
> prepared to revise your strategy later if it doesn’t work out well. (The 
> amount of code relating to file wrappers is likely to be small relative to 
> the code that generally maintains your data model, so rewriting it shouldn’t 
> be onerous. However, that suggests it would be prudent not to let the 
> wrappers propagate too deeply into the model. Keep them as an artifact of the 
> save mechanism in particular, rather than the data model in general.)
> 

Ok, thanks again for all your feedback. I took a stab at implementing it 
yesterday. Everything is in my subclass of UIDocument. The rest of the model is 
a layer below the UIDocument subclass (i.e., the subclass has a couple instance 
variables which are the main model) although I did put a few methods in the 
UIDocument class to add the images since that needs to change the NSFileWrapper.

I think I've got it working. Here is how I did it (in case this helps anyone 
else and in case anyone else sees a problem with this).

UIDocument subclass has a NSFIleWrapper instances for each of these:

1. Top level NSFileWrapper directory wrapper.
2. It contains a directory wrapper for a subdirectory named Images where all 
the image files (that won't be updated often go). I put the method to add an 
image here so that it could update the NSFileWrapper
3. a NSFileWrapper that contains a single file that is a list of all the image 
filenames that is added to the top level NSFileWrapper
4. a NSFileWrapper for the rest of the model that will change often and is 
added to the top level NSFileWrapper

Whenever an image is added, I remove the NSFileWrapper in #3 from the top level 
file wrapper, created a new NSFileWrapper with the new list of images, and then 
add that to the top level NSFileWrapper. And add the image file to the 
NSFileWrapper in #2. It appears you must call removeFileWrapper on the top 
level NSFileWrapper and then add the new NSFileWrapper with addFileWrapper 
rather than just calling addFileWrapper with the same preferred filename and 
replacement NSFileWrapper. Similarly with my #4 main data model file, I call 
removeFileWrapper and addFileWrapper each time a save occurs since this data 
changes frequently.

Since images won't be added as often as the rest of the model is updated, I'm 
hoping this won't cause these images to be re-written every time a save is 
performed but I'm not certain how to verify this is the case.

Thanks,
Dave Reed
___

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: Window updates stall on headless Mac mini

[Steve Mills]

On Mar 21, 2016, at 14:09:48, Ken Thomases  wrote:
> 
> Thread 9 is apparently what's blocking your main thread.  It is animating a 
> progress indicator.  I have encountered my own problems with this heartbeat 
> thread deadlocking Cocoa.  (You are not encountering a deadlock, per se.)  
> You can try removing the progress indicator from your UI, turn off its 
> animation, or configure it to not use threaded animation (set the 
> usesThreadedAnimation property to false; you can do this in IB via user 
> attributes).

Interesting. I'd looked at that thread and assumed that Apple knew what they 
were doing, so I ignored it. Thanks again for you expertise.

--
Steve Mills
Drummer, Mac geek


___

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: Window updates stall on headless Mac mini

[Ken Thomases]

On Mar 21, 2016, at 11:23 AM, Steve Mills  wrote:
> 
> On Mar 19, 2016, at 03:27 AM, Ken Thomases  wrote:
> 
>> No. The main thread is blocked waiting for another Cocoa thread. It's 
>> waiting on an internal pthread condition variable.
>> 
>> There must be some other thread which is going to signal that condition 
>> variable under some circumstances. In all likelihood, that other thread is 
>> blocked on something else, so you have a pseudo-deadlock.
>> 
>> Show the backtrace of all threads. Or a sample report, which has similar 
>> information.

> * thread #1: tid = 0xf3b18, 0x7fff89524136 
> libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread', 
> stop reason = signal SIGSTOP
> * frame #0: 0x7fff89524136 libsystem_kernel.dylib`__psynch_cvwait + 10
> frame #1: 0x7fff8fa8b560 libsystem_pthread.dylib`_pthread_cond_wait + 693
> frame #2: 0x7fff8dea323e AppKit`-[NSViewHierarchyLock 
> _lockForWriting:handler:] + 323

> thread #9: tid = 0xf3c4f, 0x7fff8951f4de 
> libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.appkit-heartbeat'
> frame #0: 0x7fff8951f4de libsystem_kernel.dylib`mach_msg_trap + 10
> frame #1: 0x7fff8951e64f libsystem_kernel.dylib`mach_msg + 55
> frame #2: 0x7fff8f2c16d7 CoreGraphics`_CGSSynchronizeWindowBackingStore + 
> 110
> frame #3: 0x7fff8f2850f7 CoreGraphics`CGSWindowSynchronizeBacking + 40
> frame #4: 0x7fff8f284dd8 CoreGraphics`lock_window_backing + 910
> frame #5: 0x7fff8f28491b CoreGraphics`CGSDeviceLock + 52
> frame #6: 0x7fff87ca4f94 libRIP.A.dylib`ripd_Lock + 40
> frame #7: 0x7fff87ca38dd libRIP.A.dylib`RIPLayerBltImage + 283
> frame #8: 0x7fff87ca3591 libRIP.A.dylib`ripc_RenderImage + 265
> frame #9: 0x7fff87ca9643 libRIP.A.dylib`ripc_EndLayer + 1204
> frame #10: 0x7fff8f299517 CoreGraphics`CGContextEndTransparencyLayer + 53
> frame #11: 0x7fff8824719a 
> CoreUI`CUICoreThemeRenderer::DrawProgressBar(CUIDescriptor const*) + 2904
> frame #12: 0x7fff88242ea9 CoreUI`CUICoreThemeRenderer::Draw(CUIDescriptor 
> const*, CGAffineTransform, CUIReturnInfo&) + 405
> frame #13: 0x7fff88216391 CoreUI`CUIRenderer::Draw(CGRect, CGContext*, 
> __CFDictionary const*, __CFDictionary const**) + 2275
> frame #14: 0x7fff88252d6e CoreUI`CUIDraw + 217
> frame #15: 0x7fff8ded8ada AppKit`__44-[NSAppearance 
> _drawInRect:context:options:]_block_invoke + 64
> frame #16: 0x7fff8de46f6b AppKit`-[NSCompositeAppearance 
> _callCoreUIWithBlock:] + 183
> frame #17: 0x7fff8ded8a93 AppKit`-[NSAppearance 
> _drawInRect:context:options:] + 127
> frame #18: 0x7fff8e1d9e84 AppKit`-[NSProgressIndicator _drawBar:] + 498
> frame #19: 0x7fff8e140787 AppKit`-[NSProgressIndicator heartBeat:] + 2091
> frame #20: 0x7fff8e13fbc5 AppKit`-[NSUIHeartBeat _heartBeatThread:] + 1738

Thread 9 is apparently what's blocking your main thread.  It is animating a 
progress indicator.  I have encountered my own problems with this heartbeat 
thread deadlocking Cocoa.  (You are not encountering a deadlock, per se.)  You 
can try removing the progress indicator from your UI, turn off its animation, 
or configure it to not use threaded animation (set the usesThreadedAnimation 
property to false; you can do this in IB via user attributes).

Regards,
Ken


___

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: Window updates stall on headless Mac mini

[Steve Mills]

On Mar 19, 2016, at 03:27 AM, Ken Thomases  wrote:

No. The main thread is blocked waiting for another Cocoa thread. It's waiting 
on an internal pthread condition variable.

There must be some other thread which is going to signal that condition 
variable under some circumstances. In all likelihood, that other thread is 
blocked on something else, so you have a pseudo-deadlock.

Show the backtrace of all threads. Or a sample report, which has similar 
information.

Thread 7 is what caused thread 1 to run. This scheme works on our developer 
machines and has always worked in the past on the headless servers (used to be 
Xserves, now minis), and still does work when we're screen sharing to them.

warning: could not load any Objective-C class information. This will 
significantly reduce the quality of type information available.
* thread #1: tid = 0xf3b18, 0x7fff89524136 
libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread', 
stop reason = signal SIGSTOP
* frame #0: 0x7fff89524136 libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x7fff8fa8b560 libsystem_pthread.dylib`_pthread_cond_wait + 693
frame #2: 0x7fff8dea323e AppKit`-[NSViewHierarchyLock 
_lockForWriting:handler:] + 323
frame #3: 0x7fff8df14d97 AppKit`-[NSView 
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 469
frame #4: 0x7fff8decd1ae AppKit`-[NSView displayIfNeeded] + 1876
frame #5: 0x7fff8decca09 AppKit`-[NSWindow displayIfNeeded] + 236
frame #6: 0x7fff8decc672 
AppKit`_handleWindowNeedsDisplayOrLayoutOrUpdateConstraints + 936
frame #7: 0x7fff8e602171 AppKit`__83-[NSWindow 
_postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke1540
 + 46
frame #8: 0x7fff8a7db127 
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 
23
frame #9: 0x7fff8a7db080 CoreFoundation`__CFRunLoopDoObservers + 368
frame #10: 0x7fff8a7cd188 CoreFoundation`__CFRunLoopRun + 872
frame #11: 0x7fff8a7ccbd8 CoreFoundation`CFRunLoopRunSpecific + 296
frame #12: 0x7fff91894b29 Foundation`-[NSRunLoop(NSRunLoop) 
runMode:beforeDate:] + 278
frame #13: 0x7fff918b2d9e Foundation`-[NSRunLoop(NSRunLoop) runUntilDate:] 
+ 108
frame #14: 0x00010024b74e RRD`-[MultiProgressMaster(PrivateMethods) 
_resetProgressTaskName:mainText:mainProgressValue:mainProgressMaxValue:mainProgressIndeterminate:subText:subProgressValue:subProgressMaxValue:subProgressIndeterminate:forTaskID:]
 + 3518
frame #15: 0x00010024b9b0 RRD`-[MultiProgressMaster(PrivateMethods) 
_resetProgressTaskWithInfoDict:] + 576
frame #16: 0x7fff91896dd0 Foundation`__NSThreadPerformPerform + 293
frame #17: 0x7fff8a7dba01 
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #18: 0x7fff8a7cdb8d CoreFoundation`__CFRunLoopDoSources0 + 269
frame #19: 0x7fff8a7cd1bf CoreFoundation`__CFRunLoopRun + 927
frame #20: 0x7fff8a7ccbd8 CoreFoundation`CFRunLoopRunSpecific + 296
frame #21: 0x7fff8ca6856f HIToolbox`RunCurrentEventLoopInMode + 235
frame #22: 0x7fff8ca682ea HIToolbox`ReceiveNextEventCommon + 431
frame #23: 0x7fff8ca6812b 
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
frame #24: 0x7fff8dec98ab AppKit`_DPSNextEvent + 978
frame #25: 0x7fff8dec8e58 AppKit`-[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
frame #26: 0x7fff8debeaf3 AppKit`-[NSApplication run] + 594
frame #27: 0x7fff8de3b244 AppKit`NSApplicationMain + 1832
frame #28: 0x000119f2 MM Automation`main(argc=1, 
argv=0x7fff5fbffce8) + 34 at main.m:13
frame #29: 0x000119c4 MM Automation`start + 52

thread #2: tid = 0xf3b24, 0x7fff89525232 libsystem_kernel.dylib`kevent64 + 
10, queue = 'com.apple.libdispatch-manager'
frame #0: 0x7fff89525232 libsystem_kernel.dylib`kevent64 + 10
frame #1: 0x7fff8f089615 libdispatch.dylib`_dispatch_mgr_invoke + 247
frame #2: 0x7fff8f08926e libdispatch.dylib`_dispatch_mgr_thread + 52

thread #3: tid = 0xf3b3f, 0x7fff89525682 libsystem_kernel.dylib`read + 10
frame #0: 0x7fff89525682 libsystem_kernel.dylib`read + 10
frame #1: 0x7fff91820cd7 Foundation`_NSReadFromFileDescriptorWithProgress + 
240
frame #2: 0x7fff9193fbe2 Foundation`-[NSConcreteFileHandle availableData] + 
156
frame #3: 0x0001002259a3 RRD`-[LogMaster(PrivateMethods) _logThread:] + 707
frame #4: 0x7fff91842e92 Foundation`__NSThread__main__ + 1345
frame #5: 0x7fff8fa8b05a libsystem_pthread.dylib`_pthread_body + 131
frame #6: 0x7fff8fa8afd7 libsystem_pthread.dylib`_pthread_start + 176
frame #7: 0x7fff8fa883ed libsystem_pthread.dylib`thread_start + 13

thread #4: tid = 0xf3b42, 0x7fff8951f4de 
libsystem_kernel.dylib`mach_msg_trap + 10
frame #0: 0x7fff8951f4de libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x7fff8951e64f libsystem_kernel.dylib`mach_msg + 55
frame #2: 0x7fff8a7cdeb4 

Re: NSSplitview and NSTableview

[Roland King]

> On 21 Mar 2016, at 12:05, yu...@aim.com wrote:
> 
> Hi,
> I spent sometime on this strange issue but still could not figure out.  I 
> hope i could get some help from the group.
> 
> 
> I have a NSScrollView which contains an NSSplitView; the splitView contains 
> four panes;  each pane is a NSTableView with just one row of text;
> After i added the last table view to the splitView,  i scrolled the 
> NSScrollView programmatically by the scrollView content frame size like the 
> following:
> 
> [_myScrollView contentView].frame.size.width;
> 
> 
> However, the data in the last table view does not appear until 8 seconds 
> later;  strange thing is if i clicked on its neighbor view on its left, the 
> data comes up right away.
> 
> 
> The 8 seconds delay is very puzzling and i am not sure what area i should 
> look into;  seems like the delegate on the last table view is not called 
> until 8 seconds later.
> 
> 

Did you scroll on the main thread? The delay sounds like exactly what you get 
when you do UI operations on a background thread. 
___

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: UIDocument with NSFileWrapper

[Quincey Morris]

On Mar 19, 2016, at 18:54 , davel...@mac.com wrote:
> 
> What I’m having trouble understanding is how I store the images (whose 
> filenames will vary from document to document) with NSFileWrapper. In my top 
> level directory do I have my main model file as a JSON file along with a file 
> (JSON or plist) that lists all the images and then have an Image directory 
> that another NSFileWrapper is used to read/write the images (that are stored 
> in the Image subdirectory)?
> 
> Or can I simply store all the files without a subdirectory? I still suspect I 
> need to have a file with a fixed name (such as image.plist) that tells me 
> what all the other filenames are to put in the NSFileWrapper (vs. using 
> NSFileManager to ask for the name of all the files).

There’s no correct answer to these questions. It’s a design problem whose 
answer is whatever works best in your use case. I’d recommend you start by 
choosing what looks to you like the most straightforward approach, then be 
prepared to revise your strategy later if it doesn’t work out well. (The amount 
of code relating to file wrappers is likely to be small relative to the code 
that generally maintains your data model, so rewriting it shouldn’t be onerous. 
However, that suggests it would be prudent not to let the wrappers propagate 
too deeply into the model. Keep them as an artifact of the save mechanism in 
particular, rather than the data model in general.)

___

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: NSOutlineView woes

[Quincey Morris]

On Mar 20, 2016, at 20:20 , Graham Cox  wrote:
> 
> This is driving me insane!

a. Can you produce a test project that demonstrates the behavior? (Preferably 
not via drag-and-drop, since that’s so much harder to debug.)

b. It’s not the actual problem, but I wonder why you construct the needed 
parent-relative index set by using ‘rowForItem:’? I may be wrong, but I don’t 
think we can assume that NSOutlineView keeps references to all or any subset of 
the universe of items in the list, so it may have to walk the rows starting 
from the root item, and this certainly opens the possibility of dicey behavior 
if your data structures are in the process of being changed. I certainly 
wouldn’t assume it can find the row more efficiently than you can find the 
child index. Since you know the child, you know the parent, so you can find 
child index by iterating linearly through the parent’s children yourself.

c. There’s also a logic issue here. It’s not clear whether you’re making a 
mistake, or the mistake is only an apparent consequence of the way you’ve 
described your methodology: It is incorrect, in general, to compute the child 
index by subtracting the child row from the parent row, because there may be 
intervening children which themselves have children.

___

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