Re: Root URL and URLByDeletingLastPathComponent

[thatsanicehatyouhave]

On Jul 18, 2016, at 7:37 AM, Mike Abdullah  wrote:

> Fair enough, thanks! I would say then yes, it’s a mismatch between the docs 
> and the implementation.
> 
> File a radar, but don’t expect the real-world behaviour to change, especially 
> any time soon! It’s far more likely they will declare it to be a mistake in 
> the docs and correct those.

Done: rdar://problem/27405026 if anyone comes across this and wants to +1 it.

Thanks,
Demitri
___

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

debugging a deadlock involving NSViewHierarchyLock

[Alan Snyder]

I have an application that occasionally deadlocks with the main thread calling 
-[NSViewHierarchyLock _lockForWriting:handler:] and no other thread stack 
showing any operation in progress that might need to own this lock. I saved a 
core dump. Is there any way I can poke around in the core dump using lldb to 
find out which thread owns the lock?


___

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: Unit testing with mixed Swift & Objective C

[David Catmull]

I found another solution: set the header search paths in the test target so
it can find the App-Swift.h file from the app target, include that in the
ObjC tests that need the Swift classes (instead of the one generated for
the test target), and then remove all the app Swift files from the test
target.

Using an auto-generated header from another target is kind of a hack, but
it works, and it's the simplest solution so far, so I'm going with it for
now.

On Sun, Jul 17, 2016 at 2:16 PM, David Catmull 
wrote:

> After converting some parts of my project to Swift, I've run into some
> problems with my tests.
>
> The first problem was where an app (not test) function, in Swift, was
> iterating over an NSArray of instances of a Swift class, because that array
> was generated by Objective C code. It was throwing an exception because the
> objects were of the wrong type. I eventually figure out that it was because
> my Swift files are in both the app and test targets, so there are two
> versions of each Swift class.
>
> For Swift tests, I understand that you're now supposed to not have your
> Swift sources in the test target, and instead use "@testable import
> MyAppModule". But what about test written in Objective C that need to
> access my Swift classes? If they're not in the test target, they won't be
> in AppTest-Swift.h. Is there some other way to generate a Swift header file?
>
> Without that, I'm looking at two alternatives for the NSArray iterating
> scenario:
> - Rewrite the function that does the iterating, using Objective C so that
> it doesn't do the type checking.
> - Rewrite the function that creates the array, using Swift so that
> hopefully the classes will match.
>
> Any other recommendations?
>
> --
> David Catmull
> davidcatm...@gmail.com
> http://uncommonplace.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

Communication with privileged helper crashes my main application

[Mark Allan]

Hi all,

I have an application which installs and uses a privileged helper tool that, 
for myself and most users, seems to work just fine.

I do, however, have one user (and experience tells me there'll be more who 
simply aren't reporting it) who's experiencing my app crashing when 
communicating with the helper tool.

I still need to support OS X 10.6, so I'm using the BetterAuthorizationSample 
code and the crash appears to be happening in BetterAuthorizationSampleLib.c at 
line 1665.  The error I'm seeing is

Assertion failed: (err == noErr), function BASSetDefaultRules

To me, that would indicate the user has the wrong version of the helper tool 
for the app in use, but from the diagnostics report being sent back, they are 
using the correct version of the helper with the correct version of the 
application so I've no idea what could be going wrong.

Has anyone else experienced this?  If so, do you have any suggestions please?

Many thanks
Mark


___

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: Keyboard/Mouse Event Interaction

[Dave]

Yes, I guess because in this case then is the possibility of the Mouse/Finger 
moving outside the Control between the Down and Up events…...

> On 18 Jul 2016, at 14:05, dangerwillrobinsondan...@gmail.com wrote:
> 
> To be fair, iOS and mouse events tend to finish on the concept of up. 
> (Though often it's up & inside to trigger some action)
> 
> Sent from my iPhone
> 
>> On Jul 18, 2016, at 10:00 PM, Steve Mills > > wrote:
>> 
>>> On Jul 18, 2016, at 07:52:02, Dave  wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks, I’m looking at it now.
>>> 
>>> I’m a bit confused over the keyboard handling. I would have thought that 
>>> the processing would take place on the KeyUp event, but it seems like its 
>>> occurring on the KeyDown event which is where I am going wrong. 
>>> 
>>> I’m not sure what use NSKeyUp is in this case? The other thing is that a 
>>> KeyDown with the AutoRepeat flag == YES seems to imply a an NSKeyUp? IOW, 
>>> the events I see are:
>>> 
>>> NSKeyDownRepeat == NO
>>> NSKeyDownRepeat == YES) If the Key is held down…..
>>> NSKeyDownRepeat == YES)
>>> NSKeyDownRepeat == YES)
>>> NSKeyDownRepeat == YES)
>>> NSKeyUpRepeat == NO
>> 
>> Nope, as you discovered, KeyDown is where the action usually happens for 
>> most things, because if it waited for KeyUp, then all the KeyRepeats that 
>> came after the KeyDown would be missed, and you don't want to queue them all 
>> up and release them on KeyUp. Just think of how it works when you're in a 
>> text editor and hold down a key (just make sure you have that stupid system 
>> pref set to NOT show the silly alt key popup thing, but work like a real key 
>> repeat should).
>> 
>> --
>> 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/dangerwillrobinsondanger%40gmail.com
>>  
>> 
>> 
>> This email sent to dangerwillrobinsondan...@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/dave%40looktowindward.com 
> 
> 
> This email sent to d...@looktowindward.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: Keyboard/Mouse Event Interaction

[dangerwillrobinsondanger]

To be fair, iOS and mouse events tend to finish on the concept of up. 
(Though often it's up & inside to trigger some action)

Sent from my iPhone

> On Jul 18, 2016, at 10:00 PM, Steve Mills  wrote:
> 
>> On Jul 18, 2016, at 07:52:02, Dave  wrote:
>> 
>> Hi,
>> 
>> Thanks, I’m looking at it now.
>> 
>> I’m a bit confused over the keyboard handling. I would have thought that the 
>> processing would take place on the KeyUp event, but it seems like its 
>> occurring on the KeyDown event which is where I am going wrong. 
>> 
>> I’m not sure what use NSKeyUp is in this case? The other thing is that a 
>> KeyDown with the AutoRepeat flag == YES seems to imply a an NSKeyUp? IOW, 
>> the events I see are:
>> 
>> NSKeyDownRepeat == NO
>> NSKeyDownRepeat == YES) If the Key is held down…..
>> NSKeyDownRepeat == YES)
>> NSKeyDownRepeat == YES)
>> NSKeyDownRepeat == YES)
>> NSKeyUpRepeat == NO
> 
> Nope, as you discovered, KeyDown is where the action usually happens for most 
> things, because if it waited for KeyUp, then all the KeyRepeats that came 
> after the KeyDown would be missed, and you don't want to queue them all up 
> and release them on KeyUp. Just think of how it works when you're in a text 
> editor and hold down a key (just make sure you have that stupid system pref 
> set to NOT show the silly alt key popup thing, but work like a real key 
> repeat should).
> 
> --
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: Keyboard/Mouse Event Interaction

[Steve Mills]

On Jul 18, 2016, at 07:52:02, Dave  wrote:
> 
> Hi,
> 
> Thanks, I’m looking at it now.
> 
> I’m a bit confused over the keyboard handling. I would have thought that the 
> processing would take place on the KeyUp event, but it seems like its 
> occurring on the KeyDown event which is where I am going wrong. 
> 
> I’m not sure what use NSKeyUp is in this case? The other thing is that a 
> KeyDown with the AutoRepeat flag == YES seems to imply a an NSKeyUp? IOW, the 
> events I see are:
> 
> NSKeyDown Repeat == NO
> NSKeyDown Repeat == YES   ) If the Key is held down…..
> NSKeyDown Repeat == YES   )
> NSKeyDown Repeat == YES   )
> NSKeyDown Repeat == YES   )
> NSKeyUp   Repeat == NO

Nope, as you discovered, KeyDown is where the action usually happens for most 
things, because if it waited for KeyUp, then all the KeyRepeats that came after 
the KeyDown would be missed, and you don't want to queue them all up and 
release them on KeyUp. Just think of how it works when you're in a text editor 
and hold down a key (just make sure you have that stupid system pref set to NOT 
show the silly alt key popup thing, but work like a real key repeat should).

--
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: Keyboard/Mouse Event Interaction

[Dave]

Hi,

Thanks, I’m looking at it now.

I’m a bit confused over the keyboard handling. I would have thought that the 
processing would take place on the KeyUp event, but it seems like its occurring 
on the KeyDown event which is where I am going wrong. 

I’m not sure what use NSKeyUp is in this case? The other thing is that a 
KeyDown with the AutoRepeat flag == YES seems to imply a an NSKeyUp? IOW, the 
events I see are:

NSKeyDown   Repeat == NO
NSKeyDown   Repeat == YES   ) If the Key is held down…..
NSKeyDown   Repeat == YES   )
NSKeyDown   Repeat == YES   )
NSKeyDown   Repeat == YES   )
NSKeyUp Repeat == NO

All the Best
Dave
  

> On 18 Jul 2016, at 13:05, dangerwillrobinsondan...@gmail.com wrote:
> 
> You might review the Event programming guide (especially the part about short 
> circuiting) and the responder chain. 
> That will pull this together in some detail. 
> 
> Sent from my iPhone
> 
>> On Jul 18, 2016, at 7:57 PM, Dave  wrote:
>> 
>> Hi Alastair,
>> 
>> Thanks a lot for this - it makes my life harder but at least I know how it 
>> works now.
>> 
>> All the Best
>> Dave
>> 
>>> On 17 Jul 2016, at 21:03, Alastair Houghton  
>>> wrote:
>>> 
>>> On 17 Jul 2016, at 14:06, Dave  wrote:
 
 My question is, do the keyboard and Mouse Down Events come in pairs, so 
 that the following would/should not occur:
>>> 
>>> No.  KeyDown happens when the key goes down, KeyUp happens when they key 
>>> comes back up.  Likewise with MouseDown and MouseUp, and they can happen in 
>>> any order relative to one another (or relative to another KeyDown/Up or 
>>> MouseDown/Up).
>>> 
 Thanks a lot for any info on this. From looking at it, I think that the 
 MouseDown/Up and KeyboardDown/Up must come if pairs with no events to the 
 other device(s) in between, but it would be nice to know for sure!
>>> 
>>> The reason you see this kind of behaviour sometimes is that *some* views 
>>> process events in a loop in their -mouseDown: handler.  See this blog post 
>>> I wrote in 2007 about event handling, which shows two different ways of 
>>> handling -mouseDown: and talks a bit about eating keypresses during 
>>> processing.
>>> 
>>> https://alastairs-place.net/blog/2007/11/19/commands-and-mo/
>>> 
>>> Kind regards,
>>> 
>>> Alastair.
>>> 
>>> --
>>> http://alastairs-place.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/dangerwillrobinsondanger%40gmail.com
>> 
>> This email sent to dangerwillrobinsondan...@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: Keyboard/Mouse Event Interaction

[dangerwillrobinsondanger]

You might review the Event programming guide (especially the part about short 
circuiting) and the responder chain. 
That will pull this together in some detail. 

Sent from my iPhone

> On Jul 18, 2016, at 7:57 PM, Dave  wrote:
> 
> Hi Alastair,
> 
> Thanks a lot for this - it makes my life harder but at least I know how it 
> works now.
> 
> All the Best
> Dave
> 
>> On 17 Jul 2016, at 21:03, Alastair Houghton  
>> wrote:
>> 
>> On 17 Jul 2016, at 14:06, Dave  wrote:
>>> 
>>> My question is, do the keyboard and Mouse Down Events come in pairs, so 
>>> that the following would/should not occur:
>> 
>> No.  KeyDown happens when the key goes down, KeyUp happens when they key 
>> comes back up.  Likewise with MouseDown and MouseUp, and they can happen in 
>> any order relative to one another (or relative to another KeyDown/Up or 
>> MouseDown/Up).
>> 
>>> Thanks a lot for any info on this. From looking at it, I think that the 
>>> MouseDown/Up and KeyboardDown/Up must come if pairs with no events to the 
>>> other device(s) in between, but it would be nice to know for sure!
>> 
>> The reason you see this kind of behaviour sometimes is that *some* views 
>> process events in a loop in their -mouseDown: handler.  See this blog post I 
>> wrote in 2007 about event handling, which shows two different ways of 
>> handling -mouseDown: and talks a bit about eating keypresses during 
>> processing.
>> 
>> https://alastairs-place.net/blog/2007/11/19/commands-and-mo/
>> 
>> Kind regards,
>> 
>> Alastair.
>> 
>> --
>> http://alastairs-place.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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: Root URL and URLByDeletingLastPathComponent

[Mike Abdullah]

Fair enough, thanks! I would say then yes, it’s a mismatch between the docs and 
the implementation.

File a radar, but don’t expect the real-world behaviour to change, especially 
any time soon! It’s far more likely they will declare it to be a mistake in the 
docs and correct those.

Mike.

> On 17 Jul 2016, at 22:06, Charles Srstka  wrote:
> 
>> On Jul 17, 2016, at 5:30 AM, Mike Abdullah > > wrote:
>> 
>> It might be a mishandling of the two sorts of rot URL. If you try feeding in 
>> this URL manually:
>> 
>> file://localhost/ 
>> 
>> and removing the last component, what do you end up with?
> 
> import Foundation
> 
> let url = NSURL(string: "file://localhost/ ")!
> print(url.URLByDeletingLastPathComponent!)
> 
> outputs:
> 
> file://localhost/../ 
> 
> 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: Keyboard/Mouse Event Interaction

[Dave]

Hi Alastair,

Thanks a lot for this - it makes my life harder but at least I know how it 
works now.

All the Best
Dave

> On 17 Jul 2016, at 21:03, Alastair Houghton  
> wrote:
> 
> On 17 Jul 2016, at 14:06, Dave  wrote:
>> 
>> My question is, do the keyboard and Mouse Down Events come in pairs, so that 
>> the following would/should not occur:
> 
> No.  KeyDown happens when the key goes down, KeyUp happens when they key 
> comes back up.  Likewise with MouseDown and MouseUp, and they can happen in 
> any order relative to one another (or relative to another KeyDown/Up or 
> MouseDown/Up).
> 
>> Thanks a lot for any info on this. From looking at it, I think that the 
>> MouseDown/Up and KeyboardDown/Up must come if pairs with no events to the 
>> other device(s) in between, but it would be nice to know for sure!
> 
> The reason you see this kind of behaviour sometimes is that *some* views 
> process events in a loop in their -mouseDown: handler.  See this blog post I 
> wrote in 2007 about event handling, which shows two different ways of 
> handling -mouseDown: and talks a bit about eating keypresses during 
> processing.
> 
>  https://alastairs-place.net/blog/2007/11/19/commands-and-mo/
> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.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