Re: Documentation Workflow

[Slipp Douglas Thompson]

Alternatively, there's always archive.org's Wayback Machine.

For example, the Core Data Programming Guide from 2014-07-03 is available right 
here: 
https://web.archive.org/web/20140703032131/https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html#//apple_ref/doc/uid/TP40001075
 .  Both the HTML & PDFs are archived, so the PDF is downloadable from the 
“PDF” link (which gives you 
https://web.archive.org/web/20140702154734/https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/CoreData.pdf
 ).

Since developer.apple.com's URL paths have changed quite a bit with the recent 
narrow-body-giant-text-ification, I plugged 
https://developer.apple.com/library/ios/navigation/ into the Wayback Machine ( 
https://developer.apple.com/library/mac/navigation/ also works), chose a 
capture date a couple years ago, and then used the “Documents [ ] 
4293 of 4293” search input to find the doc I was looking for.

— Slipp


> On Dec 2, 2016, at 10:36 AM, 2551phil <2551p...@gmail.com> wrote:
> 
> 
>> On 2 Dec 2016, at 23:25, Richard Charles  wrote:
>> 
>> Somebody needs to start an online repository of older Apple developer 
>> documentation in pdf format.
> 
> I did do exactly that for the legacy AppleScript stuff[1] when it started 
> disappearing, but it’d be a bit of a mammoth task to do the same for the 
> whole of the Cocoa APIs. The best alternative I found once Apple removed the 
> PDFs was to use Dash[2]. 
> 
> [1]. https://applescriptlibrary.wordpress.com
> [2]. https://kapeli.com/dash
> 
> 
> 
> Best
> 
> 
> Phil
> ___
> 
> 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/apple%2Bcocoa-dev%40slippyd.com
> 
> This email sent to apple+cocoa-...@slippyd.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: Documentation Workflow

[Slipp Douglas Thompson]

No, you don't need to know HTML or CSS to get this to work.

Here's a basic step-by-step:

1. Download & install the Stylish plugin/add-on/extension for your browser of 
choice.  The official userstyles.org Stylish is available for Chrome ( 
https://chrome.google.com/webstore/detail/stylish/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en
 ) and Firefox ( https://addons.mozilla.org/en-us/firefox/addon/stylish/ ), 
though it looks like someone else made a Safari version ( 
http://sobolev.us/stylish/ ).
2. Download the 2 files from that gist.
3. Open up the Stylish plugin/add-on/extension's UI and click the import 
button, choose one file, then click import and choose the other file.
4. Enjoy better layout/styling whenever you visit a URL matching 
`http[s]://developer.apple.com/reference/*`.  ;-)
5 (optional). Stylish for Chrome allows you to toggle styles on & off for the 
current page by clicking the toolbar icon for the extension (to the right of 
the address bar; the Stylish extension's icon is an “S” in a 4-colored square), 
so you can decide on-the-fly if you really want to use these changes or not.  
I'd imagine Stylish for other browsers works similarly.
6 (optional). Modify the CSS to your liking.  The most obvious point of 
customization would be the `font-size: 10pt !important;` line— you can change 
the `10pt` to `12pt` or `24pt` or `6pt` or whatever other numerical font size 
you please.



Also, I'm not sure if those images went through, so here they are again, hosted 
externally:

Turns this: https://cl.ly/0m1c462d1z40
Into this: https://cl.ly/2b03340B3F2y

— Slipp


> On Nov 17, 2016, at 8:55 AM, Richard Charles <rcharles...@gmail.com> wrote:
> 
> 
>> On Nov 17, 2016, at 6:45 AM, Slipp Douglas Thompson 
>> <apple+cocoa-...@slippyd.com> wrote:
> 
> [snip]
> 
>> I got tired of the layout issues and cooked up some quick Stylish CSS to 
>> rectify developer.apple.com/reference/* pages.
> 
> [snip]
> 
>> My Stylish CSS (in Mozilla Format) can be found at: 
>> https://gist.github.com/capnslipp/208d50e8a6c630d053b4f22e704f28a5
>> 
>> — Slipp
> 
> How about some simple instructions for those of us who don’t know html and 
> are not web developers on how to get this to work? Do you do something like 
> this?
> 
> http://stackoverflow.com/questions/7173096/how-to-apply-default-css-styling-to-all-html-pages
> 
> --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: Prioritizing drawing of the important stuff

[Slipp Douglas Thompson]

You could just set up a simple debounce timer— reset it back to 0sec elapsed 
time whenever the slider is updated, and if it reaches a small delay then the 
HQ image is rendered (and remains on-screen until the slider is later moved and 
the process repeats).  No need to rely on GCD or threading.

— Slipp

> On Oct 29, 2016, at 4:37 AM, Jonathan Taylor  
> wrote:
> 
> Hi all,
> 
> This is a bit of a general question, but hopefully people may have some 
> suggestions. I've got some drawing code that synthesizes an image in a 
> window, which will change in response to sliders (e.g. changing the camera 
> perspective). My problem is how to make it so that the redrawing of the image 
> is as responsive as possible as the slider moves.
> 
> At the moment I just respond to KVO notifications from the slider by 
> redrawing. This works fairly well. However, after further development work my 
> program is now a bit more complicated. Effectively, I have two images, one of 
> which is expensive to draw and one less so. What I would like is to have the 
> quick-to-draw one update fairly often, and the more expensive one at lower 
> priority. Does anyone have any suggestions about how to achieve this?
> 
> Ideally, I would like the quick image to continue to update responsively as 
> the slider moves. I am less bothered about how responsive the slow image is. 
> One way I could do this is to treat it as low priority, either though a low 
> priority GCD thread or through coalescing post-when-idle NSNotifications. My 
> experiments so far, though, suggest that this is a rather binary thing. The 
> low priority thing only really runs  when *nothing* else at all is happening. 
> This can lead to a scenario where (as far as I can tell via Instruments) the 
> OS is spending every moment of idle time redrawing a moving slider at some 
> outrageous frequency, making it look ultra-smooth, but not dedicating *any* 
> time at all to doing my low-priority drawing.
> 
> So, I think this basically boils down to a question of load balancing. Is 
> there a good way to balance the time my code spends on different drawing 
> activities, making sure all do happen to some extent, but some more often 
> than others? Importantly (and most challengingly I think) this includes UI 
> drawing activities that the OS undertakes on my behalf (which I have less 
> control over).
> 
> I fear there is no easy solution to this, but if anyone has any suggestions 
> for things I should look at, that would be really helpful.
> 
> Cheers
> Jonny.
> ___
> 
> 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/apple%2Bcocoa-dev%40slippyd.com
> 
> This email sent to apple+cocoa-...@slippyd.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: Stupid objective-c question

[Slipp Douglas Thompson]

I'm just going to throw this out there as a solution, not because I recommend 
this approach (it's API misuse after all) but because it would work.

Instead of using an `NSString *` you could use a `SEL` (AKA `struct 
objc_selector *`) since SELs are guaranteed to be unique for each given string 
they represent (within a process; AFAIR).

So your code would become:

if (context == @selector(mediaLibraryLoaded))
{
// …

Or in Swift:

if context == Selector("mediaLibraryLoaded")
{
// …
(Swift's `Selector.init(_ str:String)` implementation 

 just calls `sel_registerName` and (curiously) treats the returned pointer as a 
C-string.)

Again, this is a blatant mis-use of the Objective-C API… but it is also a 
built-in compiler-optimized guaranteed-interned string, it won't cause issues 
when comparing to other arbitrary `void *`s, and the usage in Swift is almost 
identical to Objective-C.





My 2¢: I'm still in favor of making all usages of `context` in your app 
`NSObject *`s or `nil` because sometimes you do want to store an `NSDictionary 
*` or other data in `context` that's meant to be read later.  But if you're 
stuck with using other libs that don't use `NSObject *`s or `nil`, or if you 
really want to ensure your code won't crash because its making assumptions 
about what's in the  `context` your code registered, then I acknowledge your 
case.  Key point: I personally wouldn't use the `SEL` approach, but still.

— Slipp



> On Sep 24, 2016, at 12:34 AM, Graham Cox  wrote:
> 
> 
>> On 24 Sep 2016, at 12:13 PM, Uli Kusterer  
>> wrote:
>> 
>>> I expect the first thing -isEqualToString: does is a pointer comparison, so 
>>> it’s unlikely to be significantly less performant for the case of when the 
>>> pointers are literally identical.
>> 
>> No, Graham, don't do that!
>> 
>> There is no guarantee that the context is a valid object. It is just 
>> supposed to be a unique pointer value so your class can tell a KVO 
>> notification from notifications for other observers on the same object (e.g. 
>> if a subclass observes the same value as a base class).
> 
> 
> Yep, I’ve realised (from this discussion) that that’s an invalid assumption 
> of another kind.
> 
> I’ve been revising code that does this as a result.
> 
> Always something to learn :)
> 
> —Graham
> 
> 
> 
> ___
> 
> 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/apple%2Bcocoa-dev%40slippyd.com
> 
> This email sent to apple+cocoa-...@slippyd.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: Stupid objective-c question

[Slipp Douglas Thompson]

> On Sep 21, 2016, at 8:00 PM, Slipp Douglas Thompson 
> <apple+cocoa-...@slippyd.com> wrote:
> 
>> On Sep 21, 2016, at 17:01 , Graham Cox <graham@bigpond.com> wrote:
>>> 
>>> This should be: if([(NSString*)context 
>>> isEqualToString:@“mediaLibraryLoaded”])…
>> 
>> Actually, this is not a good idea either, because *other* observations — 
>> ones you don’t control — might use a value that’s not an object, or not even 
>> a valid pointer.
> 

I see your point about context plausibly not being neither an NSObject nor nil. 
 While you could check if context is an NSObject beforehand (is there even a 
reliable way to do this?  CocoaWithLove 
<http://www.cocoawithlove.com/2010/10/testing-if-arbitrary-pointer-is-valid.html>
 couldn't find a great approach ;-/)— I think coding consistently against all 
other addObserver: calls in your app is a good-enough solution.  I.E. If you 
implement observeValueForKeyPath: with [context isEqual: …] checks, make sure 
all the other addObserver: calls (for those same keys, at least) are using nil 
or NSObjects.

Thoughts?

— Slipp
___

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: Stupid objective-c question

[Slipp Douglas Thompson]

> On Sep 21, 2016, at 17:01 , Graham Cox  wrote:
>> 
>> This should be: if([(NSString*)context 
>> isEqualToString:@“mediaLibraryLoaded”])…
> 
> Actually, this is not a good idea either, because *other* observations — ones 
> you don’t control — might use a value that’s not an object, or not even a 
> valid pointer.


Looking over a couple of open-source implementations of Foundation (cocotron 
, 
PureFoundation 
), the 
first check done in both isEqual: & isEqualToString: is a pointer == check.  

So yes, isEqualToString: could cause issues here so isEqual: is the most 
sure-fire solution (IMHO)— it shouldn't be any less performant than 
isEqualToString: and only marginally less performant than a == (due to 
objc_msgSend overhead).

— Slipp
___

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: Stupid objective-c question

[Slipp Douglas Thompson]

> Whenever I have two string literals @"XYZ" at different places in the same 
> compilation unit,
> and the XYZ are identical, then the compiler (or the Objective-C standard) 
> make sure that
> the pointers to those literals are identical?
> 
> In other words, the compiler unifies the two occurrences of the two literals, 
> thus effectively storing only one literal?

Yes that's why it works in your test, but as Graham Cox said, you “are taking 
advantage of undocumented implementation details”.  This behavior is not a 
standard at all.


> So what would be the proper way to do it?  Should I just define my own string 
> constant?

As others have suggested, always use isEqual: or isEqualToString: when doing 
NSString comparisons, never ==.  The Obj-C implementation does a pointer 
comparison first, so isEqual:/isEqualToString: do not incur a significant 
performance cost in this situation.

— Slipp



> On Sep 21, 2016, at 7:05 PM, Gabriel Zachmann  wrote:
> 
> 
>>> 
>>> how can the compiler know that '==' in this case is a NSString comparison?
>> 
>> It can’t because it isn't. What’s being compared are raw pointers. The 
>> string value is irrelevant.
> 
> Let me try to paraphrase, in order to check whether I am understanding 
> correctly.
> 
> Whenever I have two string literals @"XYZ" at different places in the same 
> compilation unit,
> and the XYZ are identical, then the compiler (or the Objective-C standard) 
> make sure that
> the pointers to those literals are identical?
> In other words, the compiler unifies the two occurrences of the two literals, 
> thus effectively storing only one literal?
> 
> 
>> So, this technique is generally Not A Good Idea™.
> 
> 
> If my understanding is correct, then I wholeheartedly agree.
> 
> That brings me to another question.  I've got this piece of code from an 
> example on MLMediaLibrary.
> 
> This is how I start the whole thing:
> 
>  [mediaLibrary_ addObserver: self
>  forKeyPath: @"mediaSources"
> options: 0
> context: (__bridge void *) @"mediaLibraryLoaded"];
> 
> And this is the beginning of the corresponding KVO:
> 
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>   change: (NSDictionary *) change context: (void *) 
> context
> {
>  MLMediaSource * mediaSource = [mediaLibrary_.mediaSources objectForKey: 
> MLMediaSourcePhotosIdentifier];
>  if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>  {
> 
> 
> So what would be the proper way to do it?  Should I just define my own string 
> constant?
> 
> 
> 
> Best regards, 
> Gabriel.
> 
> 
> 
> ___
> 
> 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/apple%2Bcocoa-dev%40slippyd.com
> 
> This email sent to apple+cocoa-...@slippyd.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