Hacker News Reader

> Passing a constant buffer to a fragment shader will cause it to be truncated at 64k on some graphics drivers. Not a bug, just an undocumented limitation. Doesn't happen on my computer. That was fun to figure out.

That doesn't even begin to scratch the surface of OpenGL bugs on Apple devices. Many more are documented here: https://github.com/servo/webrender/wiki/Driver-issues

OpenGL is technically deprecated on Apple's platforms, so you're not likely to get much support either…

> If you'd like to know why an exception was thrown, you have to print the value of the proper CPU register. On x86-64 it's $rax. As far as I know this is an oral tradition, passed down from senior developer to junior developer.

This varies based on the calling convention and signature of the the method that the exception handler puts a breakpoint on. With objc_exception_throw on x86_64 the value should be in $rdi ($arg1) in LLDB.

> If you want a daemon to survive the user logging out and logging in, you have to use a barely-documented function (bootstrap_parent) which is only mentioned in a now-archived tech note.

It's also mentioned in Mac OS X Internals: A Systems Approach, FWIW.

It’s always a good sign when the document that explains a piece of functionality no longer bears the same name as the operating system it purports to document.

This comment nicely sums up one of the things that's wrong with the Apple ecosystem --- apparently, whatever backwards-compatibility Apple does manage to have gets dismissed by developers because "it's old".

...and then they wonder why they can't find the old docs that actually have what they need. Apple thinks the developers don't care, and vice-versa. It's a cycle of negative feedback.

On most other platforms, the assumption is that things will not change between versions, and changes are explicitly mentioned and documented when they do occur, but Apple and its developers seem to have the exact opposite mentality.

I hope you didn’t imply that I’m what’s wrong with the Apple developer ecosystem. Old is fine, as long as it is still accurate. I have spent more time than you could imagine digging through ancient cocoadev mailing list posts and WebKit Trac bugs in order to debug problems with my apps. There is nothing more frustrating than having the only available reference be out of date, and having to synthesize the gaps.

That’s kind of hard to avoid if it’s a physical book and the subject changes names.

I think his point is that it should be documented online, in an ever-green knowledge base...

It's a third party technical book, not an Apple document. No reason to expect it to be reissued because of a later Apple marketing decision.

> It's also mentioned in Mac OS X Internals: A Systems Approach, FWIW.

It's funny you should mention this. After someone sent me an amazing pull request using this call, I thought "hm, this should be in Mac OS X Internals: A Systems Approach. Why didn't I see it?" So I looked it up, and yes, it's there, but there's nowhere near enough context or description for it to be of use to anyone but (at most) the author. Here's what it says:

The /usr/libexec/StartupItemContext program can be used to run an executable in the startup context—that is, the context in which the Mac OS X startup items run. It works by calling bootstrap_parent() repeatedly until it has reached the startup (root) context. It then sets the port as its own bootstrap port, after which it can execute the requested program.

The automatic relaunching of servers by the Bootstrap Server is useful for creating crash-resistant servers. However, it is neither necessary not advisable to create production servers by directly using the Bootstrap Server interface. Beginning with MacOS X 10.4, the launch API, as exported through <launch.h>, should be used. With this caveat, let us look at two examples of using the Bootstrap Server interface.

[an example that shows how to list all known services]

[a rather complex example that creates a bootstrap service and maybe uses bootstrap_parent somewhere]

There are bits of wisdom in this wonderfully written (and of course now obsolete) tech note:

https://developer.apple.com/library/archive/technotes/tn2083...

But of course, most people just copy-paste from the code Apple has (I would guess grudgingly) made open-source and we hope for the best.

Yup! I mentioned in another comment here, but overriding scrollWheel can completely kill smooth scrolling and is only mentioned in some release notes.

It's crazy.

It is mentioned a few times, but never w/ any reference or explanation :-) Could someone please provide some pointers on this?

So, I know they were in the 10.9 release notes, because 10.9 was where smooth scrolling was introduced. However... as is typical, I cannot even seem to find those release notes now?

Someone appears to have mirror them in a gist, so open this (https://gist.github.com/zwaldowski/8710fddc8b0b39d2c152) and ctrl+f for "Responsive Scrolling".

> Do not override -scrollWheel: in an NSScrollView, NSClipView subclass, or in the document view.

> If you'd like to know why an exception was thrown, you have to print the value of the proper CPU register.

I'm not sure what you mean. To see why an exception was thrown you can call [-NSException reason][0]. If you're stopped in your catch block in the debugger, it's as simple as typing:

> call (NSString*)[e reason]

Assuming your exception is named "e".

[0]https://developer.apple.com/documentation/foundation/nsexcep...

I read the "Of Mice and Men" investigation. It was a good read. But I guess the kicker is that this code is in fact written by Apple for WebKit long before Google forked Blink (do a git blame; and see notes that "if you linked on Tiger or above"). I would've thought for all the vague public-facing documentation, Apple's internal documentation must be better. I guess that's not so.

If the Metal debug layer doesn’t warn you, then it is a bug (either in the driver or in the debug layer depending on the intended behaviour).