Re: Bind View-Based NSTableView to array of dictionaries in user defaults

[Jerry Krinock]

> On 2016 May 06, at 07:58, Keary Suska  wrote:

> If you substitute with a cell-based table, it works flawlessly.
> I was able to get it to work properly by proxy-ing the array in the app 
> delegate

Keary, thank you very much for taking the time to test my demo project, and 
digging in to discover those two quite interesting facts.

> I would file a radar, FWIW.

Done: 26151911

In a new commit, I have updated the demo project’s README.md to reflect Keary’s 
discoveries.  The README.md is now in fact the text which I submitted to Apple. 
 Here is the link again:

https://github.com/jerrykrinock/ArrayDictionaryDefaultsDemo


___

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: Very basic need, very difficult to achieve.

[Charles Srstka]

> On May 6, 2016, at 11:19 AM, Richard Charles  wrote:
> 
> 
>> On May 5, 2016, at 10:33 PM, Charles Srstka  wrote:
>> 
>>> On May 5, 2016, at 9:39 PM, Richard Charles  wrote:
>>> 
>>> 
 On May 5, 2016, at 6:07 PM, Richard Charles  wrote:
 
 Can you run this application?
 
 “OpenGL Extensions Viewer"
 
 http://www.realtech-vr.com/glview/
 
 I could never get an app that uses OpenGL to work with a virtual machine.
>>> 
>>> 
>>> 
 On May 5, 2016, at 8:16 PM, Charles Srstka  
 wrote:
 
 Seems to run all right in VMWare Fusion on my machine.
>>> 
>>> 
>>> Amazing.
>>> 
>>> Click the “Tests” tab and click the “Test” button in the lower left corner.
>>> 
>>> Does it work?
>>> 
>>> --Richard Charles
>> 
>> I got an image of a rotating cube.
>> 
>> Charles
> 
> Interesting.
> 
> According to VMware Fusion 8 Documentation a Mac OS X Virtual Machine does 
> not support 3D Accelerated graphics.
> 
> http://pubs.vmware.com/fusion-8/index.jsp#com.vmware.fusion.using.doc/GUID-474FC78E-4E77-42B7-A1C6-12C2F378C5B9.html
> 
> I just called VMware technical support and they confirmed that the product 
> does not support support 3D Accelerated graphics with a Mac virtual machine.
> 
> So what is happening? Perhaps you are seeing the Apple OpenGL Software 
> Renderer being utilized by the OpenGL Extensions Viewer application. You can 
> set this with a pull down at the top of the window.
> 
> I am currently developing a Mac application that uses OpenGL but I could 
> never get it to work with Parallels. I was never able to get the application 
> to fall back to using the Apple Software Renderer when OpenGL hardware was 
> not present. Perhaps I was not doing something correctly.

It does appear to be using the software renderer. However, the cube does 
display and do its rotating thing.

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: Very basic need, very difficult to achieve.

[Sandor Szatmari]

I can't say that this is complete or there won't be any gotchas for specific 
use cases, but here's what I can think of.

1. Preserving access in the App Store
If you don't "Purchase" the OS installer before the next release  you 
won't be able to download a new copy in the future.
So...
Whenever a new OS is released I "Purchase" the installer, download it, 
and archive it.
After it finishes downloading, the installer launches, quit the 
installer and copy the app to a safe permanent storage location.
Delete the installer application from /Applications
This process should make sure you have a local cache of installers and 
download access to the installer in the future through the App Store.
2. Creating Installers
In general, I just install on an external USB hard drive.  I use 16 GB 
USB sticks.
Here are some instructions
Lion and Mountain Lion

http://www.macworld.com/article/1167857/software-system/how-to-make-a-bootable-mountain-lion-install-drive.html
Mavericks and Beyond
https://support.apple.com/en-us/HT201372
Once I create an installer USB stick I keep it around, for the cost and 
headache its just easier.
3. Installing operating systems (Old and New)
Occasionally Apple introduces new hardware that does not support older 
OS's.
Occasionally Apple introduces new Software that does not support older 
hardware.
So, to be thorough, you need to maintain an awareness of what your 
hardware supports, and don't ditch your older machines so easily.
Virtual machines are a good work around if you don't have actual 
hardware that supports the OS you want to install on.  But there may be 
limitations.
4. Virtual Machines
Ever since Apple allowed virtualization Parallels and VMWare are great
Its nice to be able to take a snapshot and mess around break stuff and 
then rollback and test some more.
If you do a lot of work in virtual machines vagrant 
(https://www.vagrantup.com) is a pretty cool.  It facilitates rapid setup and 
switching between VMs.  It works with virtualbox and VMWare, not sure about 
Parallels.
There may be some limitations for specific development needs as some 
have pointed out, hardware acceleration support.  The only thing we trust at 
work is tests verified on actual hardware.


Sandor

> On May 4, 2016, at 08:29, Alex Zavatone  wrote:
> 
> Considering that we all will need to perform this joyous process when we 
> least expect it and have the least time to do it. Would it be possible to 
> bulletpoint the process to serve as a reference?
> 
> One thing I have noticed with some of the more recent versions of OS X (10.9 
> I think) is that once upgraded, HFS will no longer recognize volumes from 
> previous incarnations of the Mac OS.
> 
> This caused great panic on my end since it was unexpected, but it is 
> important to note if you are trying to install a prior OS to a volume where 
> the format or partition or whatever is not recognized by the HFS version of 
> the OS you are trying to install.
> 
> Just a nice detail.
> 
> To mitigate this pain, I keep several VMWare Fusion VMs around at 40 GB a 
> piece and when a new OS comes out, I duplicate the latest one, upgrade it, 
> install Xcode on it and move forward.
> 
> This way, I can always spoil up an older OS with a working version of Xcode 
> on it if needed.
> 
> Keeping these on a cheap and large HD and moving the one needed to an SSD is 
> a cost efficient manner of keeping working older OSes with functional Xcode 
> installs around if needed.
> 
> Hope this helps anyone who might have to go through Graham's lovely ordeal.
> 
> Cheers,
> 
> Alex Zavatone
> 
> Sent from my iPhone
> 
>> On May 4, 2016, at 7:41 AM, Sandor Szatmari  
>> wrote:
>> 
>> Glad you got it to work.  I have seen the installer 'could not be verified' 
>> before.  The only time I saw that was after using command line copy (cp) to 
>> copy the installer app.  But except for that one experience, using 
>> createmediainstaller has worked well.  I also copy the installer to 
>> someplace outside /Applications like Phil (sqwarqDev) suggested before 
>> letting it run.  Basically the installer app that I archive is a pristine, 
>> never been run, download.  And then I make USB sticks directly off of those 
>> archived apps.
>> 
>> Sandor
>> 
>>> On May 4, 2016, at 01:33, Graham Cox  wrote:
>>> 
>>> 
 On 3 May 2016, at 8:28 PM, Graham Cox  wrote:
 
 So probably a redownload isn’t going to help, but I’m doing it anyway.
>>> 
>>> 
>>> Success! Finally.
>>> 
>>> I created a new bootable installer using createinstallmedia and a fresh 
>>> Mavericks download. I did the Pacific Daylight Time change just in case 
>>> (though it sounds like voodoo, I’m prepared 

Re: Receiver type for instance message is a forward declaration

[Quincey Morris]

On May 6, 2016, at 14:58 , Alex Zavatone  wrote:
> 
> Can we come up with a suitable set of tests to replicate and verify this

This was the code from the forum thread that I played around with:

> class ViewController: UIViewController {  
> let backgroundQueue = dispatch_queue_create("backgroundQueue", 
> DISPATCH_QUEUE_SERIAL);  
> var tickTimer: NSTimer?  
>  
> var cancelTimer: NSTimer?  
>  
> override func viewDidLoad() {  
> super.viewDidLoad()  
>  
> tickTimer = NSTimer.scheduledTimerWithTimeInterval(0.1, target: self, 
> selector: "timerFired:", userInfo: nil, repeats: true)  
>  
> cancelTimer = NSTimer.scheduledTimerWithTimeInterval(30, target: 
> self, selector: "cancelTimerFired:", userInfo: nil, repeats: false)  
> }  
>  
> func timerFired(timer: NSTimer) {  
> for _ in 0..<100 {  
>  
> dispatch_async(backgroundQueue, { () -> Void in  
> // TODO: some calculation. However, it does not matter  
> })  
> }  
> }  
>  
> func cancelTimerFired(timer: NSTimer) {  
> tickTimer?.invalidate()  
> }  
> }


But it only be a problem with specific OS X or iOS versions. I haven’t checked 
lately.

___

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: Receiver type for instance message is a forward declaration

[Carl Hoefs]

> On May 6, 2016, at 2:34 PM, Quincey Morris 
>  wrote:
> 
> On May 6, 2016, at 13:32 , Carl Hoefs  > wrote:
>> 
>> Once in a while, NSOperationQueue -addOperation: throws an exception. I 
>> guess this is a well-known bug going all the way back to 2008. I found Mike 
>> Ash's writeup on the issue, and have downloaded his replacement class, 
>> RAOperationQueue. However, it was written long ago for GC not ARC.
> 
> As a side issue, you didn’t give us any explicit references to Mike’s 
> discussion, but looking back through his blog 
> (mikeash.com/pyblog/use-nsoperationqueue.html 
> ), I see that he 
> reported that *his* problem was fixed in 10.5.7:
> 
>> "Mac OS X 10.5.7 has shipped and includes a fix for the NSOperationQueue bug 
>> that I discovered late last year. I have run all of my old test cases 
>> against 10.5.7 and it appears to perform as advertised. As far as I can see, 
>> NSOperationQueue is now safe to use.”
> 
> 
> These days, if I had any doubts about NSOperationQueue, I’d switch to using 
> GCD directly. There’s very little that NSOperationQueue does that GCD 
> doesn’t, and I must admit I’ve never regarded NSOperationQueue as superior**, 
> apart from the fact that it got here first. (IIRC) NSOperationQueue started 
> to displace raw threading only just before GCD arrived on the scene.

I've noticed infrequent objcExceptionThrow()s using NSOperationQueue for quite 
a while now, always thinking it must be something I'm doing. Unfortunately, the 
exception appears so seldom that I've never had the time to look into the issue 
at the time it happens. All I'm doing is -addOperation: when it blows. I can't 
reproduce it at will. I should have taken a stack trace when it occurred today. 

Sadly, RAOperationQueue et al is suffering from code rot. I couldn't get it to 
work at all. Thanks for the GCD suggestion as an alternative, I'll go with it. 
(It isn't that NSOperationQueue is superior to GCD or not, it was just a very 
conveniently-oriented object to use.)
-Carl

___

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: Receiver type for instance message is a forward declaration

[Alex Zavatone]

Can we come up with a suitable set of tests to replicate and verify this, like 
a bunch of dispatch_async calls to increment an NSInteger and then to decrement 
the NSInteger that repeats while true?

Sent from my iPhone

> On May 6, 2016, at 5:34 PM, Quincey Morris 
>  wrote:
> 
> ** There is, however, a small cloud hovering over GCD. This has been reported 
> in the developer forums independently by different developers. Apparently, a 
> GCD queue (under what circumstances isn’t clear) can use additional memory 
> for each block that’s ever queued. That is, if a queue has historically run 
> and disposed of N blocks, it will keep N * X bytes of memory around, even 
> though its queue might currently be empty. The value of X is very small, so 
> you have to go through tens of thousands of blocks before you’d even notice. 
> It’s not clear if this is a memory leak, or a cache that would eventually 
> stop increasing in size and/or be reclaimed.

___

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: Receiver type for instance message is a forward declaration

[Quincey Morris]

On May 6, 2016, at 13:32 , Carl Hoefs  wrote:
> 
> Once in a while, NSOperationQueue -addOperation: throws an exception. I guess 
> this is a well-known bug going all the way back to 2008. I found Mike Ash's 
> writeup on the issue, and have downloaded his replacement class, 
> RAOperationQueue. However, it was written long ago for GC not ARC.

As a side issue, you didn’t give us any explicit references to Mike’s 
discussion, but looking back through his blog 
(mikeash.com/pyblog/use-nsoperationqueue.html), I see that he reported that 
*his* problem was fixed in 10.5.7:

> "Mac OS X 10.5.7 has shipped and includes a fix for the NSOperationQueue bug 
> that I discovered late last year. I have run all of my old test cases against 
> 10.5.7 and it appears to perform as advertised. As far as I can see, 
> NSOperationQueue is now safe to use.”


These days, if I had any doubts about NSOperationQueue, I’d switch to using GCD 
directly. There’s very little that NSOperationQueue does that GCD doesn’t, and 
I must admit I’ve never regarded NSOperationQueue as superior**, apart from the 
fact that it got here first. (IIRC) NSOperationQueue started to displace raw 
threading only just before GCD arrived on the scene.


** There is, however, a small cloud hovering over GCD. This has been reported 
in the developer forums independently by different developers. Apparently, a 
GCD queue (under what circumstances isn’t clear) can use additional memory for 
each block that’s ever queued. That is, if a queue has historically run and 
disposed of N blocks, it will keep N * X bytes of memory around, even though 
its queue might currently be empty. The value of X is very small, so you have 
to go through tens of thousands of blocks before you’d even notice. It’s not 
clear if this is a memory leak, or a cache that would eventually stop 
increasing in size and/or be reclaimed.


___

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: Receiver type for instance message is a forward declaration

[Jens Alfke]

> On May 6, 2016, at 1:42 PM, Carl Hoefs  wrote:
> 
> I would have thought that this earlier line would have been flagged if 
> RAOperation.h hadn't been included:
> 
>   RAOperation *op = [self _popOperation: listPtr];

There must be a forward declaration (“@class RAOperation”) somewhere above, 
possibly in your class’s header. After a forward declaration, you can refer to 
the class and declare references to instances. But since the compiler has no 
idea what the class’s interface is, or even what it’s superclass is, it will 
complain if you try to message a reference.

—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: Receiver type for instance message is a forward declaration

[Carl Hoefs]

> On May 6, 2016, at 1:35 PM, John McCall  wrote:
> 
>> On May 6, 2016, at 1:32 PM, Carl Hoefs  
>> wrote:
>> I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in 
>> a while, NSOperationQueue -addOperation: throws an exception. I guess this 
>> is a well-known bug going all the way back to 2008. I found Mike Ash's 
>> writeup on the issue, and have downloaded his replacement class, 
>> RAOperationQueue. However, it was written long ago for GC not ARC. I have 
>> one remaining problem in converting the code.
>> 
>> - (BOOL)_runOperationFromList: (RAAtomicListRef *)listPtr sourceList: 
>> (RAAtomicListRef *)sourceListPtr
>> {
>>  RAOperation *op = [self _popOperation: listPtr];
>>  if( !op )
>>  {
>>  *listPtr = RAAtomicListSteal( sourceListPtr );
>>  // source lists are in LIFO order, but we want to execute 
>> operations in the order they were enqueued
>>  // so we reverse the list before we do anything with it
>>  RAAtomicListReverse( listPtr );
>>  op = [self _popOperation: listPtr];
>>  }
>>  
>>  if( op )
>>  [op run];  <-- ERROR HERE
>>  
>>  return op != nil;
>> }
>> 
>> The error I'm getting is: Receiver type 'RAOperation' for instance message 
>> is a forward declaration.
>> 
>> What does this error mean, and how can I fix it?
> 
> It means you haven't #included the header with the @interface declaration for 
> RAOperation.
> 
Indeed, that silenced the error, thanks! 
I would have thought that this earlier line would have been flagged if 
RAOperation.h hadn't been included:

RAOperation *op = [self _popOperation: listPtr];

-Carl


___

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: Receiver type for instance message is a forward declaration

[John McCall]

> On May 6, 2016, at 1:32 PM, Carl Hoefs  wrote:
> I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in a 
> while, NSOperationQueue -addOperation: throws an exception. I guess this is a 
> well-known bug going all the way back to 2008. I found Mike Ash's writeup on 
> the issue, and have downloaded his replacement class, RAOperationQueue. 
> However, it was written long ago for GC not ARC. I have one remaining problem 
> in converting the code.
> 
> - (BOOL)_runOperationFromList: (RAAtomicListRef *)listPtr sourceList: 
> (RAAtomicListRef *)sourceListPtr
> {
>   RAOperation *op = [self _popOperation: listPtr];
>   if( !op )
>   {
>   *listPtr = RAAtomicListSteal( sourceListPtr );
>   // source lists are in LIFO order, but we want to execute 
> operations in the order they were enqueued
>   // so we reverse the list before we do anything with it
>   RAAtomicListReverse( listPtr );
>   op = [self _popOperation: listPtr];
>   }
>   
>   if( op )
>   [op run];  <-- ERROR HERE
>   
>   return op != nil;
> }
> 
> The error I'm getting is: Receiver type 'RAOperation' for instance message is 
> a forward declaration.
> 
> What does this error mean, and how can I fix it?

It means you haven't #included the header with the @interface declaration for 
RAOperation.

John.
___

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

Receiver type for instance message is a forward declaration

[Carl Hoefs]

I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in a 
while, NSOperationQueue -addOperation: throws an exception. I guess this is a 
well-known bug going all the way back to 2008. I found Mike Ash's writeup on 
the issue, and have downloaded his replacement class, RAOperationQueue. 
However, it was written long ago for GC not ARC. I have one remaining problem 
in converting the code.

- (BOOL)_runOperationFromList: (RAAtomicListRef *)listPtr sourceList: 
(RAAtomicListRef *)sourceListPtr
{
RAOperation *op = [self _popOperation: listPtr];
if( !op )
{
*listPtr = RAAtomicListSteal( sourceListPtr );
// source lists are in LIFO order, but we want to execute 
operations in the order they were enqueued
// so we reverse the list before we do anything with it
RAAtomicListReverse( listPtr );
op = [self _popOperation: listPtr];
}

if( op )
[op run];  <-- ERROR HERE

return op != nil;
}

The error I'm getting is: Receiver type 'RAOperation' for instance message is a 
forward declaration.

What does this error mean, and how can I fix it?
-Carl

___

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: NSTableView is messaging zombie delegate

[Jens Alfke]

> On May 6, 2016, at 1:03 PM, Matthew LeRoy  wrote:
> 
> My understanding is that NSTableView's delegate is a zeroing weak reference

Are you sure? Historically it’s been unsafe_unretained — in the old days before 
weak references or ARC, the view never retained nor released the delegate. The 
type of crash you’re having was a not-uncommon bug.

Apple may have upgraded the property to a proper zeroing weak reference, but I 
can’t tell from the docs. They simply say "In a managed memory environment, the 
table view maintains a weak reference to the delegate (that is, it does not 
retain the delegate).” I’m assuming ARC counts as “managed”, but that sentence 
does not include the word “zeroing”…

I would play it safe and explicitly set the table view’s delegate to nil when 
tearing down the window. I usually do this in the windowWillClose delegate 
method.

—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: NSTableView is messaging zombie delegate

[Jonathan Mitchell]

> On 6 May 2016, at 21:03, Matthew LeRoy  wrote:
> 
> Hello,
> 
> I'm having an issue where an NSTableView appears to be messaging its delegate 
> after the delegate has been deallocated, causing an EXC_BAD_ACCESS crash. It 
> doesn't always happen, but it happens regularly. My understanding is that 
> NSTableView's delegate is a zeroing weak reference, and so I'm stumped as to 
> how/why it is sending a message to the delegate after the delegate has been 
> deallocated.
Its a weak reference, not a zeroing weak reference.
So when your delegate disappears the NSTableView delegate still points to it 
unless you manually intervene.
You only get the zeroing weak behaviour when you build with arc.
I don’t know if AppKit is built with arc enabled or not but the NSTableView 
delegate is declared as a getter/setter pair rather than a weak property.

This catches us out because we are used to seeing the arc zeroing behaviour in 
our own arc enabled code.
We forget that some of the objects we interact with don’t act quite the same. 

WebView delegates for instance behave in the same way.
I generally set my table and web view delegates to nil in the NSViewController 
dealloc - this precaution seems to pay off in terms of increased stability when 
view hierarchies get torn down.
 
J
___

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

NSTableView is messaging zombie delegate

[Matthew LeRoy]

Hello,

I'm having an issue where an NSTableView appears to be messaging its delegate 
after the delegate has been deallocated, causing an EXC_BAD_ACCESS crash. It 
doesn't always happen, but it happens regularly. My understanding is that 
NSTableView's delegate is a zeroing weak reference, and so I'm stumped as to 
how/why it is sending a message to the delegate after the delegate has been 
deallocated.

The basic scenario is that my application shows a custom modal sheet which 
contains an NSTableView. The NSWindow for the sheet is loaded from a Nib via an 
NSWindowController, and contains (among other things) an empty NSView which is 
a placeholder for additional UI. An NSViewController loads the additional UI 
(which includes the NSTableView) from a separate Nib and the UI is placed in 
the placeholder NSView within the NSWindow. The application holds a reference 
to the NSWindowController, which holds a reference to the NSViewController, 
which has a *weak* reference (outlet) to the NSTableView. The NSTableView's 
delegate is its File's Owner (the NSViewController).

The crash can be made to happen simply by showing the sheet ([NSApp 
beginSheet:...]), then immediately closing it ([NSApp endSheet:returnCode:], 
followed by [sheet orderOut:self], [sheet close], _windowController = nil;). 
Again, it doesn't happen every time, but when it does it appears that the 
NSTableView sends -respondsToSelector: to its delegate, even though the 
delegate (the NSViewController) has been deallocated. Here's the stack trace 
from the crash log:

Application Specific Information:
objc_msgSend() selector name: respondsToSelector:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib 0x7fff9267d4dd objc_msgSend + 29
1   com.apple.AppKit0x7fff975fa76d -[NSTableRowData 
_removeViewAndAddToReuse:forRow:] + 163
2   com.apple.CoreFoundation0x7fff98e11496 
__65-[__NSDictionaryM 
enumerateKeysAndObjectsWithOptions:usingBlock:]_block_invoke + 102
3   com.apple.CoreFoundation0x7fff98e11389 -[__NSDictionaryM 
enumerateKeysAndObjectsWithOptions:usingBlock:] + 185
4   com.apple.AppKit0x7fff9779941c -[NSTableRowData 
_removeNonVisibleViewsInDictionary:] + 88
5   com.apple.AppKit0x7fff9753900c -[NSTableRowData 
_removeRowsBeingAnimatedOff] + 60
6   com.apple.Foundation0x7fff84a09b4e 
__NSFireDelayedPerform + 377
7   com.apple.CoreFoundation0x7fff98e1cb94 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
8   com.apple.CoreFoundation0x7fff98e1c823 __CFRunLoopDoTimer + 
1075
9   com.apple.CoreFoundation0x7fff98e1c37a __CFRunLoopDoTimers 
+ 298
10  com.apple.CoreFoundation0x7fff98e13871 __CFRunLoopRun + 1841
11  com.apple.CoreFoundation0x7fff98e12ed8 CFRunLoopRunSpecific 
+ 296
12  com.apple.HIToolbox 0x7fff882f7935 
RunCurrentEventLoopInMode + 235
13  com.apple.HIToolbox 0x7fff882f7677 
ReceiveNextEventCommon + 184
14  com.apple.HIToolbox 0x7fff882f75af 
_BlockUntilNextEventMatchingListInModeWithFilter + 71
15  com.apple.AppKit0x7fff97431df6 _DPSNextEvent + 1067
16  com.apple.AppKit0x7fff97431226 -[NSApplication 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
17  com.apple.AppKit0x7fff97425d80 -[NSApplication run] 
+ 682
18  com.apple.AppKit0x7fff973ef368 NSApplicationMain + 
1176
19  libdyld.dylib   0x7fff984505ad start + 1

I've reproduced the crash using the Zombies template in Instruments, and it 
indicates that the NSViewController is indeed the zombie object that is being 
sent the -respondsToSelector: message.

I've pored over the retain/release log in Instruments for the NSViewController 
instance and everything appears to be in order - in order words, I don't think 
I'm over-releasing it. Based on my debugging, the NSTableView appears to be 
living on well after the NSWindowController has been released and deallocated 
(which causes the NSViewController to also be released and deallocated). I 
would've expected that the NSTableView would be deallocated before the 
NSViewController or NSWindowController since I'm not holding any references to 
it elsewhere, but it appears it isn't deallocated until later (I have confirmed 
that it is in fact being deallocated eventually). Still, even if the 
NSTableView outlives its delegate, shouldn't the delegate reference get zeroed 
when the delegate gets deallocated? Why isn't it in this case?

Notably, this code hasn't changed and has been in the field for at least 6 
months, and we only first started seeing the crash when testing on 10.11.4. It 
also happens regularly on the latest 10.11.5 beta. We initially thought it was 
limited to 

Re: Very basic need, very difficult to achieve.

[Richard Charles]

> On May 5, 2016, at 10:33 PM, Charles Srstka  wrote:
> 
>> On May 5, 2016, at 9:39 PM, Richard Charles  wrote:
>> 
>> 
>>> On May 5, 2016, at 6:07 PM, Richard Charles  wrote:
>>> 
>>> Can you run this application?
>>> 
>>> “OpenGL Extensions Viewer"
>>> 
>>> http://www.realtech-vr.com/glview/
>>> 
>>> I could never get an app that uses OpenGL to work with a virtual machine.
>> 
>> 
>> 
>>> On May 5, 2016, at 8:16 PM, Charles Srstka  wrote:
>>> 
>>> Seems to run all right in VMWare Fusion on my machine.
>> 
>> 
>> Amazing.
>> 
>> Click the “Tests” tab and click the “Test” button in the lower left corner.
>> 
>> Does it work?
>> 
>> --Richard Charles
> 
> I got an image of a rotating cube.
> 
> Charles

Interesting.

According to VMware Fusion 8 Documentation a Mac OS X Virtual Machine does not 
support 3D Accelerated graphics.

http://pubs.vmware.com/fusion-8/index.jsp#com.vmware.fusion.using.doc/GUID-474FC78E-4E77-42B7-A1C6-12C2F378C5B9.html

I just called VMware technical support and they confirmed that the product does 
not support support 3D Accelerated graphics with a Mac virtual machine.

So what is happening? Perhaps you are seeing the Apple OpenGL Software Renderer 
being utilized by the OpenGL Extensions Viewer application. You can set this 
with a pull down at the top of the window.

I am currently developing a Mac application that uses OpenGL but I could never 
get it to work with Parallels. I was never able to get the application to fall 
back to using the Apple Software Renderer when OpenGL hardware was not present. 
Perhaps I was not doing something correctly.

--Richard 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: Bind NSTableView to array of dictionaries in user defaults

[Keary Suska]

> On May 5, 2016, at 7:47 PM, Jerry Krinock  wrote:
> 
> After reading Quincey’s reply, I had concluded that this is one of those 
> cases where Cocoa Bindings requires additional “glue”, which defeats one of 
> the two purposes of Cocoa Bindings.  But it would be very cool if there were 
> some configuration change that would be make this work in both directions.  
> It seems like we’re really close.
> 
> I’m accustomed to doing this kind of code-less binding to a Core Data model, 
> wherein it “just works”.  That’s not surprising, because of course Core Data 
> knows the data model in great detail.  It can observe everything.

Trying out your example it looks like both you and Quincey may be correct, but 
on the opposite ends. The issue appears to be something with how view-based 
tables work, rather than NSArrayController. If you substitute with a cell-based 
table, it works flawlessly. The issue seems to involve binding through 
objectValue, so I guess you are back to needing some kind of glue code.

I was able to get it to work properly by proxy-ing the array in the app 
delegate, so this must specifically be an interaction between view-based tables 
and NSUserDefaultsController. I would file a radar, FWIW.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: Can't make an adaptive segue push

[Roland King]

> On 6 May 2016, at 20:49, Roland King  wrote:
> 
> I have a navigation controller as the detail pane of a UISplitView (pretty 
> much right from the standard splitview template). 
> 
> Now I want to push another view onto that stack. I have the view, I’ve 
> dragged out a segue to connect it up however none of the available ‘adaptive 
> segues’ do a ‘push’. Even the ‘Show (Push)’ one doesn’t push, it replaces the 
> view entirely and removes the nav controller. 
> 
> If I use the deprecated ‘push’ segue, then it pushes, but it’s deprecated and 
> gives me a handy yellow triangle warning me of such. 
> 
> Am I falling foul of the splitview controller’s adaptation here somehow? I’m 
> a little hazy on the way adaptive segues work but it feels like the ‘show’ is 
> being sent up to and interpreted by the splitview controller and doing a 
> replace on the detail pane instead of a push. But it could be something 
> entirely different. 
> 
> I could hook the button up to make the new view controller and push it 
> instead of using a segue, but I’d rather not. Is there a way I can make 
> ‘Show’ do a ‘Push’?

As usual, asking the question made me think about it and get the answer. 
Override showDetailViewController:sender: to do the push (or something else if 
appropriate in that adaptation which in this case is always push). If not, the 
targetViewController is found which is the splitview controller which does a 
detail pane replace. 

This stuff sometimes almost makes sense, if you don’t think about it too hard. 


___

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

Can't make an adaptive segue push

[Roland King]

I have a navigation controller as the detail pane of a UISplitView (pretty much 
right from the standard splitview template). 

Now I want to push another view onto that stack. I have the view, I’ve dragged 
out a segue to connect it up however none of the available ‘adaptive segues’ do 
a ‘push’. Even the ‘Show (Push)’ one doesn’t push, it replaces the view 
entirely and removes the nav controller. 

If I use the deprecated ‘push’ segue, then it pushes, but it’s deprecated and 
gives me a handy yellow triangle warning me of such. 

Am I falling foul of the splitview controller’s adaptation here somehow? I’m a 
little hazy on the way adaptive segues work but it feels like the ‘show’ is 
being sent up to and interpreted by the splitview controller and doing a 
replace on the detail pane instead of a push. But it could be something 
entirely different. 

I could hook the button up to make the new view controller and push it instead 
of using a segue, but I’d rather not. Is there a way I can make ‘Show’ do a 
‘Push’?
___

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