Re: Help Indexing

[Frank D. Engel, Jr.]

Help index seems fine, and I finally tried on a fresh Mac (with a newer 
OS version at that) and no joy there either.


At this point, since it is really only one of these anchors to a page of 
help anyway, I am thinking I will rework to name the files what I was 
previously calling the anchors and just open the online help in a web 
browser, maybe an embedded one in a custom window, to bypass this entire 
mess.


Such an ill-behaved help system is not befitting of Apple.


On 4/18/2017 16:03, Jerome Krinock wrote:

On 2017 Apr 18, at 01:22, Frank D. Engel, Jr.  wrote:

I switched them to “id"…

I tried clearing the cache…

… still no good.

Sorry, I forgot to mention that Apple Help can be frustrating.

I would try to determine if the .helpindex file which was produced by hiutil 
and copied to your app’s Contents/Resources is valid.  The man page for hiutil 
(man hiutil) lists several modes you can run, in particular -—list-anchors, 
whose results would be interesting.

If it looks like you have a valid .helpindex which contains your anchors, and 
is in your Help folder alongside the root .html file, then question the caching 
again – if you have handy another Mac which has never seen your Help Book, try 
your app there.



___

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: Translating KVO-ed property to Swift

[Charles Srstka]

> On Apr 24, 2017, at 1:17 PM, Quincey Morris 
>  wrote:
> 
> On Apr 24, 2017, at 10:11 , Charles Srstka  > wrote:
>> 
>> What Quincey seemed to be referring to was a property that was not backed by 
>> any kind of persistent value.
> 
> That wasn’t actually the kind of property I had in mind. I was thinking of 
> settable, computed properties that did not depend on the value(s) of other 
> KVO-observable properties. There probably aren’t many plausible *simple* 
> examples, but I was thinking of such cases as when the value is stored in an 
> I/O device rather than RAM, or when the value is retrieved from a server.

In this case, I would try to see if I could find some way to monitor changes in 
the underlying storage, and call the willChange and didChange methods manually 
when changes occur. I’d only make the property dynamic if it was completely 
impossible to do this, and I’d keep this to a last resort. The reason is 
because in this case, the property is not fully KVO-compliant, because its 
value can change without notifications being sent.

I did kind of touch on this with the UserDefaults-example I provided a while 
back. Pretending that NSUserDefaults still notified via NSNotifications only, 
as was the case before native KVO support was added to it, you would register 
for the NSNotification, check whether your default had changed, and fire the 
willSet and didSet notifications once it did. This is a lot more robust than 
depending on the automatic notifications when your property’s value may change 
without going through the property’s setter.

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: iOS "library" unit test of iOS code?

[Rick Mann]

Also, in this case, it can be a macOS thing; the code should run equally well, 
assuming the dylib I depend on can load (it might've been built against the iOS 
SDK).

> On Apr 24, 2017, at 15:48 , Jens Alfke  wrote:
> 
> 
>> On Apr 24, 2017, at 3:38 PM, Rick Mann  wrote:
>> 
>> I'm trying to test some code that's entirely stand-alone from my app, and in 
>> fact I'm having trouble testing it within my app because the app does some 
>> things that interfere.
>> 
>> So, I tried creating a new test target and specifying "None" for the Test 
>> Host, then adding the files needed to the new test target.
> 
> You can’t do that in iOS — all tests have to be run within an app.
> If you can’t run them in your regular app, you need to make a new empty app 
> and then test them in that.
> 
> —Jens


-- 
Rick Mann
rm...@latencyzero.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: iOS "library" unit test of iOS code?

[Rick Mann]

> On Apr 24, 2017, at 15:48 , Jens Alfke  wrote:
> 
> 
>> On Apr 24, 2017, at 3:38 PM, Rick Mann  wrote:
>> 
>> I'm trying to test some code that's entirely stand-alone from my app, and in 
>> fact I'm having trouble testing it within my app because the app does some 
>> things that interfere.
>> 
>> So, I tried creating a new test target and specifying "None" for the Test 
>> Host, then adding the files needed to the new test target.
> 
> You can’t do that in iOS — all tests have to be run within an app.
> If you can’t run them in your regular app, you need to make a new empty app 
> and then test them in that.

Okay, thanks.

Do Apple's docs spell this out anywhere?

-- 
Rick Mann
rm...@latencyzero.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: iOS "library" unit test of iOS code?

[Jens Alfke]

> On Apr 24, 2017, at 3:38 PM, Rick Mann  wrote:
> 
> I'm trying to test some code that's entirely stand-alone from my app, and in 
> fact I'm having trouble testing it within my app because the app does some 
> things that interfere.
> 
> So, I tried creating a new test target and specifying "None" for the Test 
> Host, then adding the files needed to the new test target.

You can’t do that in iOS — all tests have to be run within an app.
If you can’t run them in your regular app, you need to make a new empty app and 
then test them in that.

—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

iOS "library" unit test of iOS code?

[Rick Mann]

I'm trying to test some code that's entirely stand-alone from my app, and in 
fact I'm having trouble testing it within my app because the app does some 
things that interfere.

So, I tried creating a new test target and specifying "None" for the Test Host, 
then adding the files needed to the new test target.

One of these files is a .dylib (and associated module map file). I finally got 
everything to link, but at run time it couldn't find the dylib. So I added the 
path to the dylib in the runtime search path, and now it finds it, but the test 
crashes in the dyld loader:

#0  0x00010b500711 in memcmp ()
#1  0x00010b4f5abf in 
ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, 
unsigned char const*, unsigned long, long long, ImageLoader::LinkContext 
const&) ()
#2  0x00010b4f88fa in 
ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char 
const*, unsigned long, unsigned long long, unsigned long long, stat const&, 
unsigned int, unsigned int, linkedit_data_command const*, 
encryption_info_command const*, ImageLoader::LinkContext const&) ()
#3  0x00010b4f4d01 in ImageLoaderMachO::instantiateFromFile(char 
const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned 
long long, stat const&, ImageLoader::LinkContext const&) ()
#4  0x00010b4e9289 in dyld::loadPhase6(int, stat const&, char const*, 
dyld::LoadContext const&) ()
#5  0x00010b4eccac in dyld::loadPhase5(char const*, char const*, 
dyld::LoadContext const&, unsigned int&, std::__1::vector >*) ()
#6  0x00010b4eca6f in dyld::loadPhase4(char const*, char const*, 
dyld::LoadContext const&, unsigned int&, std::__1::vector >*) ()
#7  0x00010b4ec3de in dyld::loadPhase3(char const*, char const*, 
dyld::LoadContext const&, unsigned int&, std::__1::vector >*) ()
#8  0x00010b4ec05e in dyld::loadPhase1(char const*, char const*, 
dyld::LoadContext const&, unsigned int&, std::__1::vector >*) ()
#9  0x00010b4e8fed in dyld::loadPhase0(char const*, char const*, 
dyld::LoadContext const&, unsigned int&, std::__1::vector >*) ()
#10 0x00010b4e8d28 in dyld::load(char const*, dyld::LoadContext const&, 
unsigned int&) ()
#11 0x00010b4ed097 in dyld::libraryLocator(char const*, bool, char 
const*, ImageLoader::RPathChain const*, unsigned int&) ()
#12 0x00010b4f24f2 in 
ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, 
ImageLoader::RPathChain const&, char const*) ()
#13 0x00010b4f1913 in ImageLoader::link(ImageLoader::LinkContext 
const&, bool, bool, bool, ImageLoader::RPathChain const&, char const*) ()
#14 0x00010b4ea474 in dyld::link(ImageLoader*, bool, bool, 
ImageLoader::RPathChain const&, unsigned int) ()
#15 0x00010b4eeb7e in dlopen ()
#16 0x00010d73fd25 in dlopen ()
#17 0x00010c11f1c8 in _CFBundleDlfcnLoadBundle ()
#18 0x00010c11f04f in _CFBundleLoadExecutableAndReturnError ()
#19 0x00010b58c235 in -[NSBundle loadAndReturnError:] ()
#20 0x00010baf9816 in _XCTestMain ()
#21 0x00010b4de679 in ___lldb_unnamed_symbol3$$xctest ()
#22 0x00010d74265d in start ()

The dyld itself has this:

$ file iOS/Controller/lib/MyLibrary/MyLibrary.dylib 
iOS/Controller/lib/MyLibrary/MyLibrary.dylib: Mach-O universal binary with 2 
architectures: [x86_64: Mach-O 64-bit dynamically linked shared library x86_64] 
[arm64]
iOS/Controller/lib/MyLibrary/MyLibrary.dylib (for architecture x86_64): Mach-O 
64-bit dynamically linked shared library x86_64
iOS/Controller/lib/MyLibrary/MyLibrary.dylib (for architecture arm64):  Mach-O 
64-bit dynamically linked shared library arm64

I don't have source code for the library.

Perhaps it's trying to link against the iOS SDK? How do I unit test, with 
minimal overhead (i.e. without having to run my entire app) some iOS-linked 
code?

-- 
Rick Mann
rm...@latencyzero.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: Translating KVO-ed property to Swift

[Quincey Morris]

On Apr 24, 2017, at 10:11 , Charles Srstka  wrote:
> 
> What Quincey seemed to be referring to was a property that was not backed by 
> any kind of persistent value.

That wasn’t actually the kind of property I had in mind. I was thinking of 
settable, computed properties that did not depend on the value(s) of other 
KVO-observable properties. There probably aren’t many plausible *simple* 
examples, but I was thinking of such cases as when the value is stored in an 
I/O device rather than RAM, or when the value is retrieved from a server.

One problem with such examples, though, is that it’s not clear in the abstract 
whether you would keep a stored (RAM) value as well. Another problem I’ve been 
brooding over is whether a property (stored or computed) that has KVO 
dependencies can actually be regarded as a dependent property *if it has a 
setter*. Depending on the details, I suspect, the property could be regarded as 
fully dependent, partially dependent, not dependent, or not classifiable.

Separately, I’ve been brooding over the kinds of audiences that might need 
advice (advisories) about using “dynamic”. I think there’s a large fraction of 
the developer population, perhaps a majority, who aren’t aware of the details 
of how KVO notifications are implemented, and an explanation is just a 
distraction that’s more confusing than enlightening. (For any one developer, 
that can change over time, of course.)

This makes me think that there need to be two rules, one simple and one 
advanced, for two different audiences.

The simple rule applies when you allow Cocoa to generate KVO notifications 
automatically (when setters are called or when you use 
“keyPathsForValuesAffecting”), but in deference to Charles’ concerns isn’t 
quite as simple as what the documentation says. It’s now this:

> Add the “dynamic” keyword if the property has a setter.


This covers the cases where “dynamic” is absolutely required (independent 
properties), and it covers all dependent properties without a setter (which, in 
practice, is most of them). It *might* add an unnecessary “dynamic” to a 
computed property with a setter, but I really think it’s the safest solution in 
such cases.

The advanced rule goes something like this:

> For any property with a setter, if you generate notifications manually via 
> willSet/didSet, and you don’t need or want automatic notifications produced 
> by the setter, you must implement “automaticallyNotifiesObserversOf” to 
> return ‘false’, and the property doesn’t need the “dynamic” keyword. 
> Otherwise, add “dynamic” if there is a setter.


That is (I hope/intend) exactly equivalent to what Charles has being saying.

___

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: Translating KVO-ed property to Swift

[Charles Srstka]

> On Apr 24, 2017, at 10:07 AM, Richard Charles  wrote:
> 
>> 
>> On Apr 23, 2017, at 11:27 AM, Charles Srstka > > wrote:
>> 
>>> On Apr 20, 2017, at 3:06 PM, Quincey Morris 
>>> >> > wrote:
>>> 
>>> Where I disagree is in your much stronger claim that a computed property is 
>>> *necessarily* a dependent property. I think this is just false. The Swift 
>>> distinction between computed and stored properties is syntactic and has 
>>> nothing to do with KVO**. A KVO-observed computed property should 
>>> therefore, according to the documented principle, be marked “dynamic”. For 
>>> anyone following your extended principle, if it’s also a dependent 
>>> property, they can omit the “dynamic”. If not, not.
>> 
>> Do you have any example of a property not backed by anything where KVO even 
>> makes sense? The whole purpose of KVO is to watch changes to values, and if 
>> there’s no value, it seems like the wrong tool.
> 
> I have a property that returns an array. A setter for this property makes no 
> sense. The property returns a collection of managed objects that is the 
> composite value of several to-many relationships.
> 
> This property is KVO compliant and bound to the NSContentArrayBinding of an 
> array controller.
> 
> There is most likely more than one way to do this but I find using bindings 
> convienient. You can bind to a KVO compliant property. You can't bind to a 
> notification.
> 
> This is in an Objective-C project that requires interoperability with a C++ 
> library. So using Swift is not possible but maybe someday it will be.
> 
> --Richard Charles

But it sounds like this property *is* backed by a value. The backing is the 
collection of managed objects. I take it you’re simply watching changes to the 
C++ source data and calling didChange/willChange when appropriate—basically 
translating one type of notification to another. This makes perfect 
sense—although not having a setter, being marked ‘dynamic’ would not change its 
behavior at all.

What Quincey seemed to be referring to was a property that was not backed by 
any kind of persistent value. Presumably, this property would also have a 
setter, since otherwise ‘dynamic’ isn’t really in play. I’m very curious as to 
what the applicability of such a thing would be, because I can’t think of any 
myself.

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: Translating KVO-ed property to Swift

[Richard Charles]

> On Apr 23, 2017, at 11:27 AM, Charles Srstka  wrote:
> 
>> On Apr 20, 2017, at 3:06 PM, Quincey Morris 
>>  wrote:
>> 
>> Where I disagree is in your much stronger claim that a computed property is 
>> *necessarily* a dependent property. I think this is just false. The Swift 
>> distinction between computed and stored properties is syntactic and has 
>> nothing to do with KVO**. A KVO-observed computed property should therefore, 
>> according to the documented principle, be marked “dynamic”. For anyone 
>> following your extended principle, if it’s also a dependent property, they 
>> can omit the “dynamic”. If not, not.
> 
> Do you have any example of a property not backed by anything where KVO even 
> makes sense? The whole purpose of KVO is to watch changes to values, and if 
> there’s no value, it seems like the wrong tool.

I have a property that returns an array. A setter for this property makes no 
sense. The property returns a collection of managed objects that is the 
composite value of several to-many relationships.

This property is KVO compliant and bound to the NSContentArrayBinding of an 
array controller.

There is most likely more than one way to do this but I find using bindings 
convienient. You can bind to a KVO compliant property. You can't bind to a 
notification.

This is in an Objective-C project that requires interoperability with a C++ 
library. So using Swift is not possible but maybe someday it will be.

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