Re: "nw_endpoint_handler_set_adaptive…" coming from XPC service

[Jens Alfke via Cocoa-dev]

> On May 27, 2021, at 11:17 AM, Dragan Milić via Cocoa-dev 
>  wrote:
> 
> I’ve got an application, which uses (a couple of) XPC service(s) to 
> accomplish various tasks. Since recently, I don’t know when exactly but 
> probably after some macOS update, I started seeing these messages coming out 
> when XPC services are used:
> 
> [connection] nw_endpoint_handler_set_adaptive_read_handler [C1.1 
> 140.82.121.6:443 ready socket-flow (satisfied (Path is satisfied), viable, 
> interface: en1, ipv4, dns)] unregister notification for read_timeout failed

If your app works and isn't getting errors back through the API, then this is 
probably just some internal logging used by Apple. There's a lot of that stuff. 
It can be annoying to have it interspersed in your own logs, but I don't think 
there's anything you can do about it.

—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: MacOS: nonmodal NSAlert panel

[Jens Alfke via Cocoa-dev]

> On May 12, 2021, at 11:17 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I had thought it was possible on MacOS to run an NSAlert panel nonmodally…


Alerts are modal by definition, per the HIG (IIRC). If you want a non-modal 
panel, it wouldn't be an alert; you'd have to implement it yourself using an 
NSPanel.

—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: How to parse a log file

[Jens Alfke via Cocoa-dev]

> On Oct 26, 2020, at 3:01 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Is it possible to determine the exact line in the source code where the error 
> occurred?

The "+ " thing in each stack line is the byte offset from the start of the 
function, in the machine code. Not super useful by itself … 

If the symbol is simply "MyAppName + " with no function/method, then no 
symbols for your code were available at the time of the crash. That means they 
weren't embedded in the code, and no dSYM file was found.

Or, if the offset is unrealistically large (like hundreds of KB), then the 
function/method name is bogus and is simply the nearest named symbol that the 
stack-dump code could find.

I believe it's possible to use the .dSYM file that was produced with the 
release build of _that exact version_ of your app, to convert those offsets 
into line numbers — there's a tool called "symbolicate" or something like that. 
I have never done this myself so I don't know the details.

—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: App store question regarding Big Sur

[Jens Alfke via Cocoa-dev]

> On Sep 20, 2020, at 11:35 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> when I upload a new version of my app that runs under Big Sur,
> which version will the Catalina users get?

AFAIK there is just one version of your app on the store at a time. You have to 
make it compatible with all your supported OSs.

You should be able to use availability tests, or even checking the OS version, 
to be compatible with both Big Sur and earlier. What specifically is the 
problem?

—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: NSSecureCoding & Nested Collections & macOS 11

[Jens Alfke via Cocoa-dev]

That sounds like a framework bug, since the warning is telling you to use the 
method you're already using. I'd file a bug report with Apple.

—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

Anyone using CloudKit?

[Jens Alfke via Cocoa-dev]

Hey, is anyone here using CloudKit? I'm getting started with it and have 
issues. There's some content on Apple's dev forums, but frankly even the new 
improved forums have awful UX (why couldn't they have simply used Discourse?)

#1: My Apple developer account is not the same as my regular Apple ID. That 
means the records my app creates are associated with my regular ID, so when I 
go to the CloudKit Dashboard I can't look inside the private database because 
I'm signed in with a different ID. 

#2: How the heck does one write tests for CloudKit? The server-side environment 
is super test-unfriendly since there's no way to programmatically set up a 
clean slate. The only way to get a fresh empty database is to go to the 
Dashboard and manually press a button to nuke the entire dev container. The 
only real solution I can imagine is to mock the entire CK API, which is 
feasible since it seems to be implemented in Obj-C, but that would be a big 
effort and you'd have to reproduce all the behaviors of the real system, which 
aren't documented.

—Jens

PS: I'm about to cross-post this to the other cocoa-dev list at 
https://apple-dev.groups.io  … sorry for the 
duplication
___

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: AddInstanceForFactory: No factory registered for id

[Jens Alfke via Cocoa-dev]

> On Aug 19, 2020, at 8:27 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I would just like for the (error?) message in the log file to go away.

Don't worry about it. There are plenty of Apple subsystems that log warnings in 
normal operation. It would be nice if it didn't happen, but it's not your 
fault. About all you can do is file a bug report.

—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: AddInstanceForFactory: No factory registered for id

[Jens Alfke via Cocoa-dev]

> On Aug 18, 2020, at 3:18 PM, Carl Hoefs  
> wrote:
> 
> Run a test using the system .aif sound files: they won't work. 
> Convert them to .mp3 files: they do work.
> That's what I mean by "in my experience".

If NSSound won't play the system sound files, something is really messed up. 
Can you show real source code?

—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: AddInstanceForFactory: No factory registered for id

[Jens Alfke via Cocoa-dev]

> On Aug 18, 2020, at 11:10 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> In my experience, playing sounds (in macOS apps) only works when using mp3 
> files.

I disagree. NSSound supports all the formats CoreAudio does, and normally for 
brief sounds people use AIFF.

I can't imagine any feature supporting _only_ MP3; it's an archaic format. 
Apple doesn't even provide an MP3 encoder in the OS, for complicated legal 
reasons. (Yes, iTunes/Music can encode MP3s, but that's because there's en 
encoder in the app, not accessible to other software.)

—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: Relieving memory pressure

[Jens Alfke via Cocoa-dev]

> On Jun 7, 2020, at 3:27 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> For large images, this "thumbnail" can well occupy 1 GB of RAM.

That seems excessive. Shouldn’t you shrink it down to the actual screen 
resolution first?

> My current approach is to calculate the amount of unused memory,
> whenever a new images is put in the cache, and if that is below 1.5 GB, I 
> reduce the size of the cache

Memory is a complicated thing in a modern OS. Memory as address space and 
memory as RAM have little to do with each other. Trying to estimate how much 
memory is free for you to use is fairly pointless unless you want to learn a 
lot about the kernel and VM.

Usually the best compromise is to allocate purgeable address space and use that 
for your caches. The kernel can then toss out that memory and reuse it for 
something else if space runs low. There are low-level C APIs for this, and I 
think some Cocoa ones too,,but it’s been a decade since I’ve used them so I 
don’t recall the details...

—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: Finding memory leaks

[Jens Alfke via Cocoa-dev]

> On May 20, 2020, at 7:03 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> This line is in a method I declared like that:
> 
> - (void) loadNextImageWithIndex: (unsigned long) next_index image: 
> (CGImageRef *) next_image
>  withProps: (CFDictionaryRef *) next_props

Off-topic, but that's an odd signature. Wouldn't it be clearer to return the 
CFDictionaryRef instead of making it an 'out' parameter?

> The caller then makes a copy of next_props for later use, and CFRelease's 
> next_props.
> (That copy is also released later.)

The "copy" may be the same object. In CoreFoundation and Foundation, if you 
copy an immutable object, you just get back a new reference to the same object. 
Same effect, but it saves memory and time. So the leaky code may be in 
whatever's managing that copy you made.

> So it is unclear to me why the Leaks tool thinks that the above line leaks 
> memory.

Leaks can be hard to track down; I sympathize.

Avoiding CF objects as much as possible helps. Recall that an NSDictionary* is 
the same as a CFDictionaryRef. You can use bridge casts to convert, and if the 
CF ref needs to be released later, you can call CFBridgingRelease which casts 
and autoreleases in one operation.

Another useful but not-well-known function is CFAutorelease, which is the 
equivalent of pre-ARC Obj-C `autorelease`. You basically call it instead of 
CFRelease; but you can call it immediately and keep using the object, because 
autorelease just promises that the object will be released sometime later.

—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: Concurrent loading of images ?

[Jens Alfke via Cocoa-dev]

> On May 8, 2020, at 2:53 PM, Gabriel Zachmann  wrote:
> 
> But in my case, I really have just one task, so the queue would - at most - 
> contain one task at a time.

You have to consider the case where the user is flipping through images faster 
than you can load them. In that case you do get multiple tasks piling up, or 
else you have to be able to abort the current task. I don't think you can abort 
a CoreGraphics call, though, so the best you could do is check for an abort in 
between two calls.

—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: Concurrent loading of images ?

[Jens Alfke via Cocoa-dev]

> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> So, I was thinking, maybe it helps to load the next image concurrently, while 
> the current one is still being displayed.

Sure. Just be aware that if you're using NSImage, simply loading an NSImage 
does not rasterize it; the class tries to be 'lazy' about doing work. So your 
background task should explicitly render it, e.g. into an NSBitmapImageRep.

> I also read about the GCD's dispatch queues, but it seems to me that this 
> would not be the suitable approach since I always only have one task running 
> concurrently to the main thread.

Why not? Dispatch queues are always available. (The main thread is simply a 
special queue.) You can run the background task by creating a single dispatch 
queue and then using dispatch_async to call a block that does the work. The end 
of the block would call dispatch_async back to the main queue and pass the 
image as a parameter.

(Or you could use NSOperationQueue and NSOperation, although I've always found 
those classes unnecessarily complicated for simple tasks.)

—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: Creating OpenSSH compatible key pairs

[Jens Alfke via Cocoa-dev]

The Sec* APIs are a world of pain. Of anything I’ve ever programmed in, um, 42 
years, they are the ones that have gotten me closest to throwing my computer 
through a window in a rage. (Runner-up: CoreAudio.) They’re very vague and 
poorly documented, and their capabilities and behaviors vary greatly between 
Mac and iOS devices and even the iOS Simulator.

It’s been a few years since I delved into them, so I can’t help as much as I’d 
like. A few thoughts:

- Shouldn’t you be using SecKeyCreatePair to create a key-pair?
- The header at the top of the PEM data you’ll probably just have to edit 
yourself.
- The incorrect data is probably a result of using different encoding/padding 
than what SSH uses.
- Have you considered just using NSTask to call the ssh-keygen tool? If you 
don’t want to go down the crypto rabbit-hole, this might save you a lot of pain.

—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: Thunderbolt port audio programmability

[Jens Alfke via Cocoa-dev]

> On Mar 20, 2020, at 8:00 PM, Carl Hoefs  
> wrote:
> 
> when the AU subsystem renders this data, it ignores the offset and generates 
> a "corrected" X-axis-centered audio signal anyway

Interesting ... I guess there’s filtering or normalization going on at some 
stage (in software or in the DAC hardware itself.) But this is way out of my 
depth.

I’d ask on the coreaudio-dev list, if it still exists, or the equivalent area 
of Apple’s dev forum.

—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: Thunderbolt port audio programmability

[Jens Alfke via Cocoa-dev]

If you want to make more than sine waves, there are a bunch of open source 
audio libraries/programs for generating arbitrarily fancy waveforms — CSound, 
Pure Data, Max, Supercollider... These are usually used for music synthesis, 
but most of them let you do general purpose DSP type stuff. And of course they 
handle the audio output too.

https://en.wikipedia.org/wiki/Comparison_of_audio_synthesis_environments 


—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: Thunderbolt port audio programmability

[Jens Alfke via Cocoa-dev]

> On Mar 12, 2020, at 5:31 PM, Carl Hoefs  
> wrote:
> 
> In iOS, what is the current way to generate precise audio tones? 
> AVFoundation? CoreAudio? AudioUnits?

AudioUnits. It's been a long time since I worked with that API, but I'm pretty 
sure I recall some sample code showing a generator AU that emits a sine wave.

—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: Thunderbolt port audio programmability

[Jens Alfke via Cocoa-dev]

> On Mar 12, 2020, at 10:27 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I'm looking at creating an iPhone/iPad app that acts as a dual-channel 
> waveform generator. 
> 
> I see two options for the output signal medium: 
> (a) using the audio jack (on suitable devices), or 
> (b) using the Thunderbolt port

Wait … you mean Lightning, right? That's the dock connector on iOS devices. 
Thunderbolt is a super-high-speed data connection on Macs.

On devices without a headphone jack, you can use the $10 dongle that plugs into 
the Lightning connector and has a headphone jack on the other end.

—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: Handling of paths through sandbox

[Jens Alfke via Cocoa-dev]

> On Feb 12, 2020, at 8:56 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> The problem is that the path names can get very long.
> And I am going to show them to the user.

There is support in AppKit for displaying file paths to the user. Unfortunately 
it's been long enough since I used it that I can't remember what it's called 
:-p Hopefully someone else remembers?

> So rather than having the last part being chopped off (which is the important 
> part),
> I would like to remove the beginning of the path, since that is unimportant.


Generally you'd truncate the middle of the path, since the beginning of the 
path can be very important.

—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: Sorting an array

[Jens Alfke via Cocoa-dev]

> On Feb 11, 2020, at 4:59 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> First of all, what are the advantages/disadvantages of either method?

Sort descriptors are data; selectors are [references to] code. So a sort 
descriptor lets you configure the sorting without having to write any custom 
code, and there's a standard API for it. For this reason they're used by 
NSTableView to represent the column sorting, and by NSArrayController.

If you're hardcoding the sort order, which it looks like you are, then it's 
probably simpler just to go the code route and sort using a selector. (Note 
that there are also sort methods that take an NSComparator, which is just a 
typedef for a block. This is very convenient for custom sorts.

> Second, I was wondering if I could write the second method like this:
> 
>imagefiles_ = [imagefiles_ sortedArrayUsingSelector: 
> @selector(localizedStandardCompare:) ];

That won't work since imageFiles_ is a mutable array, and 
-sortedArrayUsingSelector: returns an immutable array. Use the mutable version, 
-sortArrayUsingSelector:, instead.

—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: Is it necessary to suspend/resume a dispatch queue/source on sleep/wake notifications?

[Jens Alfke via Cocoa-dev]

> On Feb 6, 2020, at 9:16 AM, Matt DeFoor via Cocoa-dev 
>  wrote:
> 
> Does anyone know if it is necessary to dispatch_suspend/resume a queue or
> source when sleep/wake notifications triggered in a macOS app?

I can’t imagine why you’d need to. When the computer goes to sleep, the CPU 
stops, so everything is implicitly suspended.

—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: How to check whether directory tree has changed?

[Jens Alfke via Cocoa-dev]

> On Dec 21, 2019, at 10:18 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Right.  I was hoping there is an easy way to do this.
> Something like a recursive check sum over the whole directory tree that the 
> OS might keep.
> I don't want to do a complete tree traversal every time the app launches.

I think you'll need to do it yourself. The FSEvents API isn't going to keep an 
infinitely long history; it certainly won't go back to before the time the OS 
booted.

You can shorten the traversal by keeping the mod date of every directory. Then 
if the mod date hasn't changed, you don't need to scan the directory contents.

You can keep the data set smaller by keeping only a hash of the collected 
names/mod dates/sizes of the files in each directory. But you do need to keep 
the info for each subdirectory to do the above optimization.

—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: NSWorkspace notifications related to time change

[Jens Alfke via Cocoa-dev]

> On Dec 18, 2019, at 11:10 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> Thanks for the suggestion. Apple docs have [[[NSWorkspace sharedWorkspace] 
> notificationCenter] in their code snippets.

The docs for that property say that it's only for use with the notifications 
declared in NSWorkspace.h.

> But [NSNotificationCenter defaultCenter] doesn't work either. Very odd. 

Usually that's the right notification center for anything not otherwise 
specified, so that's weird.
The only other notification center I know of is 
NSDistributedNotificationCenter, but that isn't used for much.

> Might there be some way in Xcode or Console to see what notifications are 
> being fired?

If you add an observer with a notification name and object of nil, it will 
receive all notifications sent to that center.

—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: Permission Denied trying to connect to localhost in unit test

[Jens Alfke via Cocoa-dev]

> On Dec 12, 2019, at 7:42 AM, Robert Walsh via Cocoa-dev 
>  wrote:
> 
> I am writing a command line application in Objective-C that needs to make a 
> TCP connection to a server.  In a unit test for the TcpClient class I am 
> writing, I have a simple TCP server that listens for connections in a thread. 
>  When I try to connect to this socket from the client socket class, connect() 
> fails and perror reports Permission Denied. 

That's odd. I've written plenty of macOS networking code and not seen this 
problem. What is the errno value?

The only thing I can guess is that the Xcode test-runner process is being 
sandboxed to prevent outgoing networking, but I've definitely run TCP 
connections from XCTests without problems. Are you connecting to "localhost" / 
127.0.0.1, or using an explicit IP address?

—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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 21, 2019, at 2:43 PM, Pascal Bourguignon via Cocoa-dev 
>  wrote:
> 
> Why couldn’t we have application developed once for a few users, and working 
> consistently over long periods, on a stable platform? 

Stable platforms don't make money. (Except maybe in the enterprise market where 
vendors sell support contracts for e.g. CentOS.)

> Currently the only solution would be to package such application in frozen 
> hardware and system software, which is not practical (users would need 
> different computers for each application!), and feasible (computers are not 
> really buillt to last more than a few year of usage).

Macs last quite a while. I have friends who still use ten-year-old MacBook Pros.

> Actually, things have changed. On Macintosh, basically an application 
> developed in 1984 against the Inside Macintosh (1.0) specifications still 
> worked in 1999 in the blue box with MacOS 9.1. 

We … _some_ applications still worked. Most would crash, or even bomb the 
OS, or misbehave; because they weren't 32-bit clean, or wrote directly to 
screen memory, or made assumptions about internal data structures, or etc. etc. 
etc. Even those that worked would show a black-and-white UI, often in a 
non-resizable 512x350 pixel window.

This level of backward compatibility was one of the things that crippled and 
almost killed Apple in the '90s. (I know, I was there.) It was nearly 
impossible to move the OS forward because any sort of modernization — like 
memory protection or multithreading — would break tons of apps. That's why 
"Rhapsody" failed. 

—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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 21, 2019, at 12:20 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> If someone can afford days/weeks to do watch WWDC sessions consistently
> every year it's great. That's not a luxury all of us can afford and it's
> ridiculous to think this should be a requirement.

All you need to watch are the keynote, and the "State Of The Union" talks the 
same day. That's maybe 3-4 hours. Or if you're really short on time you can 
read the multitude of blog posts and news articles, or read through the text 
transcripts of the talks after Apple posts those.

If you're developing for Apple platforms, you need to keep abreast of what's 
happening on those platforms. That's just common sense. Tech moves fast, and if 
you don't stay informed and stay educated, you'll be left behind.

—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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 5:21 PM, Saagar Jha  wrote:
> 
> Oh, I guess I didn’t explain what I was talking about well. I’m saying that 
> the compiler would do a full method inline but put it behind a check to see 
> if it’s legal to continue executing. 

That optimization would increase code size (it can't possibly decrease it.) And 
it can't do very effective inlining, because the code to be inlined is only 
conditionally executed, so it can't really be merged into the call site. All 
you really save is the time difference between `bar_is_unswizzled` and 
`objc_msgsend`, which probably isn't very much (although you do have better 
locality of reference.)

But I am not a compiler engineer, so this is just my hobbyist opinion :)

—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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 2:46 PM, Saagar Jha  wrote:
> 
> I am curious why this optimization went in instead of guarded speculative 
> inlining, which would let you keep dynamism. 

If I understand it correctly, that only 'inlines' (really caches) the resolved 
method address for the call site. That's not much of a win in Obj-C where 
method lookup is already quite fast.

The real win comes with literally inlining the method at compile time. 
Link-Time Optimization allows _any_ method anywhere in the program to be 
inlined, provided the call is monomorphic. And this new feature allows 
monomorphic method calls in Obj-C. This is a big win for small method like 
getters/setters, and for methods with only one call site (i.e. where you factor 
out a method for readability even though it's only used in one place.)

—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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>  wrote:
> 
> If Obj-C is dead, why is Apple still adding new language extensions (and not 
> minor one) ?
> 
> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>  
> 

Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
optimization of internal methods — not just because the call is faster, but 
because the method body is now inlineable.

I remember talk of this inside Apple way back when (early 2000s) but at the 
time IIRC it was considered too dangerous to be worth the performance gain. 
These days it's probably even more of a win because of LTO.

—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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 8:28 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> For example the vast majority of audio software
> companies are still communicating to its users to not update to Catalina.
> Huge audio companies like Native Instruments are still struggling with this.

That's misleading. Native Instruments software all runs 64-bit, as far as I'm 
aware. The issue is that a 64-bit process cannot load 32-bit plugins 
(obviously), nor communicate with a 32-bit userspace hardware driver … and many 
of NI's customers have older 3rd party VST or AU plugins or drivers that would 
stop working.

NI has previously told their customers* they can work around this by launching 
their apps in 32-bit mode, but of course that no longer works in Catalina. 
That's what the warning is about.

(There's also the fact that many major OS upgrades have changes to Core Audio 
that can cause issues with audio apps, so there always seems to be a shake-out 
period where Apple and/or the audio developer release some maintenance fixes.)

—Jens

* 
https://support.native-instruments.com/hc/en-us/articles/209592169-Managing-Applications-and-Plug-ins-on-OS-X-32-64-bit-Systems
___

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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 19, 2019, at 12:51 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> If I understand it correctly, there is a linkage between Swift and 
> Objective-C. Apple devised a way to call the Cocoa frameworks written in 
> Objective-C from the Swift language using the magic of the LLVM compiler.

The Swift compiler and runtime know how the Objective-C runtime works, so so 
Swift can treat Obj-C classes and objects as first-class citizens.

> A great question would be is possible for Apple to pull the Objective-C rug 
> out from underneath the Cocoa frameworks leaving only a Swift implementation?

Sure, since you can create Obj-C compatible classes in Swift simply by using 
the @objc annotation.

However, rewriting a framework from scratch is always a perilous activity and 
not something to be done lightly. This may happen over time, but I wouldn't 
expect wholesale rewrites in the near future.

—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: List search

[Jens Alfke via Cocoa-dev]

> On Nov 15, 2019, at 6:07 AM, Turtle Creek Software  
> wrote:
> 
> I think this list should migrate there.

We don't have any control over this list or any of the others on 
lists.apple.com . They're run by Apple, and I think 
they've either forgotten about the listserv, or they just leave it running to 
avoid pissing off the developers still using these lists.

I created the groups.io  lists a few years ago, after Apple 
shut down their xcode list, and advertised them here. That's about all we can 
do.

—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: other developer lists

[Jens Alfke via Cocoa-dev]

>>> Maybe another list for meta or post-mortem discussions could be created ?

I manage the apple-dev.groups.io  site, which 
hosts a number of Apple developer lists including a Cocoa one.

I'd be happy to create a list for these kinds of discussions, if we can come up 
with a suitable title and tag-line. (My experience is that lists created to 
host a single off-topic thread seldom live long, because their purpose is too 
specific.)

—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: Thoughts on Objective-C++

[Jens Alfke via Cocoa-dev]

> On Nov 13, 2019, at 10:58 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> Over the last 16 years would bet that a lot of spit and polish has gone into 
> integrating Cocoa with Windows by the iTunes team.

They only integrated the iTunes app with Windows. Getting a single app working 
does not make a GUI framework suitable for general use. It would have taken 
much, much more work to produce and support something that could be used by all 
app developers. And apparently Apple determined that this wasn't in their 
interest, probably with good reasons.

—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: Thoughts on Objective-C++

[Jens Alfke via Cocoa-dev]

> On Nov 11, 2019, at 10:46 AM, Turtle Creek Software  
> wrote:
> 
> That means no use of const. All pointers instead of & references.  Both of 
> those are good at turning run-time errors into compile-time.  […]  No 
> public/private to manage access. Etc. It was like going back to the early 
> 90s. Doing without features we learned to use the hard way.

Well yes, Obj-C is not a very good C++, just as C++ isn't a very good Obj-C. 
And Haskell isn't a very good Ruby, and vice versa.

I like C++ and use it daily, but I could write a litany of complaints about it 
compared to Obj-C and Swift — C++ has meager reflection/introspection, its 
collection and string APIs are horrendous, it has weak and awkward support for 
memory management, templates are a super-kludgy [SFINAE, OMG] way to implement 
generics,  it promotes writing unreadable code, etc.

I'm not just joking here. Obj-C's dynamic nature is at the heart of a lot of 
Cocoa's powerful features like Interface Builder and KVO. Super-static 
languages like C++ don't work well for GUI development, IMHO, because they make 
it hard to compose high-level objects together.

—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: Thoughts on Objective-C++

[Jens Alfke via Cocoa-dev]

> On Nov 11, 2019, at 9:28 AM, Pier Bover  wrote:
> 
> AFAIK no Apple frameworks for Swift have been (or will be) open sourced 
> either.

Not higher-level ones, but the Swift standard libraries include the equivalent 
of most of Foundation. Which is a big deal, because the lack of an open-source 
Foundation was a big roadblock to cross-platform usage of Obj-C. (I tried to 
use GNUstep for a while, but at the time their class libraries were too limited 
and buggy.)

—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: Thoughts on Objective-C++

[Jens Alfke via Cocoa-dev]

> On Nov 11, 2019, at 6:15 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Then suggest that Cocoa would work better if Obj-C were a
> superset of C++ rather than plain C.  Objective-C++ all the way down, not
> just in source files.

Obj-C++ is a superset of C++, so I’m not sure what you’re wishing for. There’s 
even pretty good interoperability between C++ and Obj-C objects: for example 
you can embed the former as an ivar, or make vectors of Obj-C classes.

>  Objective-C and Cocoa will be deprecated soon, replaced by
> Swift and SwiftUI. That way there is just one shiny new closed system for
> all Apple hardware. So much simpler.

You can’t really call it “closed” when the entire Swift toolchain and runtime 
libraries are open source, portable, and being actively used on other 
platforms. That’s more open than Obj-C, because Apple never open-sourced 
Foundation.

And it’s much more open than the platform you’re decamping to. MSVC and .NET 
are both fully closed, as far as I’m aware. And I doubt C++-to-C# integration 
is that much smoother.

—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: i386 Deprecated Warning in Xcode 9.4.1

[Jens Alfke via Cocoa-dev]

> On Oct 24, 2019, at 11:46 AM, Sandor Szatmari via Cocoa-dev 
>  wrote:
> 
> Is there a flag I can set in Xcode to squash these?

If these are compiler (Clang) warnings, then:

1. Right-click on a warning in the Xcode issues browser
2. Select "Show In Log" — this should take you to the build log with that 
warning message visible
3. At the end of the warning message should be something like "(-Wsomething)", 
which is the name of the Clang compiler flag that enables that warning.
4. Go to your target build settings, and in the custom warning flags add 
"-Wno-something", which will suppress that warning.

—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: Thoughts on productivity

[Jens Alfke via Cocoa-dev]

> On Oct 24, 2019, at 7:47 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> Before September 2014 the developer documentation was excellent. Excellent 
> online documentation with downloadable and searchable pdfs. Now all pdfs are 
> gone and online documentation is like art on display in a museum. Great to 
> look at but not very usable.

Have you tried the app Dash*? It's a general-purpose documentation browser, and 
it will automatically index and search installed Apple docsets, much better 
than Xcode does. I can't live without it. 

(I'm not doing so much Apple-specific coding these days, but I'm still 
constantly using Dash to look up C++ library classes, Mac man pages, SQLite 
syntax, Python syntax, etc. It's one of eight apps I've got hot-keys for.)

—Jens

* https://kapeli.com/dash
___

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: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 15, 2019, at 10:52 AM, Turtle Creek Software  
> wrote:
> 
> Diving down into C sounds like a reasonable option for a database library.  
> It does not sound good for a specialty app that does construction estimating 
> and accounting.

I don't see the difference, for the purposes of this discussion. Either way 
you'd have core code in C++ that you call into via a C API.

> Libraries just show Assembly when you step into them, no?  

No. Not if it's a static library; and not if it's a dynamic library you have 
symbols for, as you do if you built it.

—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: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 15, 2019, at 9:40 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> 2. Another option is Swift but it has zero integration with C++. So this is 
> really not a choice at all.

Swift integrates with C. So you can declare C APIs to your C++ codebase, and 
call those from Swift. This does mean writing a lot of C++ wrapper code in the 
form of extern "C" functions that call your C++ methods. Which is admittedly 
extra work, but hardly rocket science.

For context: I work on a database library[1] implemented in C++ that provides 
exactly such a C API, which is then used by higher-layer frameworks written in 
Objective-C, Swift, Java, and C#. So I know this works and is not an 
unreasonable amount of work. Here [2] is an example source file if you want to 
see what it looks like. (Note that some of the boilerplate is to catch 
exceptions thrown by the C++ layer; if your C++ doesn't use exceptions, you 
don't need that.)

—Jens

[1]: https://github.com/couchbase/couchbase-lite-core
[2]: 
https://github.com/couchbase/couchbase-lite-core/blob/master/C/c4DocExpiration.cc
___

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: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 15, 2019, at 6:59 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> TurtleSoft has a big investment in C++ source code that's full of
> construction business logic. Unfortunately, with the death of Carbon its
> future value is in doubt.

I know I’ve brought up Objective-C++ to you here before, but I’m not sure you 
registered its existence, based on comments like this.

Any well-designed app keeps the data model and core business logic separate 
from the UI. So having that logic in C++ is not a big problem.

As for the UI code, I’ve still never found a cross-platform UI framework that 
creates decent apps. Qt is hideous, and Electron results in immensely bloated 
websites-in-a-box. So to do a good job, you need to code the UI for each 
platform anyway.

—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: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 14, 2019, at 5:02 PM, Charles Srstka  wrote:
> 
> Swift, on the other hand, can actually *be* a scripting language if you want 
> it to; put #!/usr/bin/env swift at the top of a source file, give it execute 
> permissions, and voilà, it’ll run just like a script.

*Anything* can be a scripting language in that sense, in Unix. I could write a 
two-line script called "run_c" containing*:
#! /bin/bash
cc "$1" -o /tmp/a.out && /tmp/a.out
and put it somewhere in my path; then I can put "#! /usr/bin/env/run_c" at the 
top of any C source file and run it as a script.

To me, "scripting language" strongly implies a CLI, plus dynamic typing, and no 
boilerplate (so I can write one-line programs.)

—Jens

* Typed in Mail. Should work, but I haven't tested it.
___

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: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 14, 2019, at 11:25 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I see Computer Science students here falling into two groups. The group that 
> likes Swift generally likes scripting languages, Python, and the like.

Whoa, I completely disagree. Objective-C is much, much closer to scripting 
languages than Swift, with all of its dynamic features:

* It has the 'id' type that represents any type of object
* you can send a message to an arbitrary object whether or not its class 
declares it
* you can intercept unhandled messages and do arbitrary things to handle them
* you can add, remove or override methods at runtime
* you can even create classes at runtime

Swift is very strongly-typed and less dynamic: it's very strict and nit-picky 
about types, protocol conformance, etc. Much more like C++.

Are you lumping Swift in with scripting languages simply because its 
method-call syntax is more normal looking? Or because compiler type inference 
sometimes allows you to omit variable types?

> (There is a third group that likes both languages, but it is very small.)

Most experienced iOS/Mac developers I know like both.

—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: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

—Jens 

> On Oct 11, 2019, at 3:32 PM, tblenko--- via Cocoa-dev 
>  wrote:
> 
> I attended a public (technical) talk in Town Hall (I think it’s called) at 
> Apple shortly before or after I went to work there. It would have been around 
> 2000-2001.
> 
> The speaker’s message was that the future of the desktop was Java the 
> speaker was the manager of the compiler group responsible for Java and 
> Objective-C — and had been going back to early NeXT days. So one had to 
> conclude that he was committed to the course he described. People tried to 
> ask about Objective-C (vs. Java) and he said that Objective-C was done, he 
> clearly didn’t want to talk about that.

That was the feeling at NeXT/Apple at the time of the merger, but it had 
fizzled out by 2000. Performance of Java, especially app launch time, wasn’t 
good enough. That sounds like Steve Naroff talking (great guy), but probably no 
later than 1999.

 (I was working on Java at Apple during that time. I was a huge Java zealot 
early on, but by 2000 I’d decided it wasn’t good for desktop apps, and embraced 
Obj-C.)

—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: Need for Swift

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 8:10 PM, Kirk Kerekes via Cocoa-dev 
>  wrote:
> 
> I further infer that the perceived need arose due to the confluence of 
> aggravation over publicity over security bugs and the desire to develop 
> autonomous vehicle software. 

I don’t think so. Language people don’t develop languages for narrow reasons 
like that, and business people don’t respond to such issues by calling for a 
new programming language.

Swift has been in development since 2010, and what drove it, the people who 
originated say, was the need to go past the limits of what could be added to 
Objective-C.

> What they have ended up is a kind of disciplined, compiling Python — not 
> really a bad concept, given the goals.

I see Swift and Python as extremely different languages. Python is very 
dynamic, Swift is very static. Swift is a lot closer to Scala, C#, Go, and Rust.

—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: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 12:22 PM, Richard Charles  wrote:
> 
> A second choice "Cross-platform Cocoa App" would be great for the small 
> developer who’s focus is on business applications. All whole world doesn’t 
> revolve around games.

https://developer.apple.com/xcode/swiftui/
https://developer.apple.com/mac-catalyst/

—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: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 6:18 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Our time is best
> spent solving business-related problems.  Along the way we have learned
> many programming and human-interface skills, but the less time we need to
> spend on that, the better.

Totally reasonable. The ironic thing is that Cocoa is actually a lot easier to 
program in than Carbon (even with PowerPlant, I'd say.) But of course, any API 
you don't know is by definition harder to use than one you already know.

> If a programming environment requires zombies, disassemblers and other BS
> just to make it work, that is a big problem.

Cocoa doesn't. I've never needed to disassemble framework code since I left 
Apple. There are probably some situations when dealing with weird bugs or 
misbehaviors where it would be useful to do so, but it's not typical.

> I suspect that Cocoa source code is ancient C that is badly in need of a
> refactoring.

It's almost all Objective-C, actually. The C code is down in CoreFoundation. 
And that code gets refactored / rewritten as necessary, I'm sure — I know about 
major rewrites of NSView, NSTableView and NSTextView that occurred while I was 
still at Apple, and I'm sure there have been more since. It was very 
well-written code back then, and I'll bet it still is.

They've also done two complete redesigns — first UIKit, and now SwiftUI. You 
learn a lot when you rewrite something. SwiftUI in particular benefits from 
some big paradigm shifts (ugh) that have been happening in the field, like 
reactive programming.

> There probably are some parts of Cocoa that are extremely proprietary- but
> even then, plain old patents are better than hiding the code, as a way to
> protect the jewels. 

Not all this stuff is patentable, and patents are very expensive to file. Not 
having readily available source code to refer to raises the bar to entry.

I hope I won't offend you if I point out that as you are (as you freely admit) 
a small business that doesn't focus on CS or software engineering, you're not 
really in a position to give engineering or business advice to Apple. Apple has 
some of the best business and software people in the world, which is not to say 
that they don't make mistakes sometimes, but they generally have pretty good 
reasons for the way they do things. What you can do is give them feedback about 
your specific experience, as you're doing, and I hope that someone at Apple is 
reading this thread and taking notice.

—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: How to compile for macOS 10.11 ?

[Jens Alfke via Cocoa-dev]

> On Oct 11, 2019, at 1:36 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> But a customer tells me that it does not work under El Capitan on their 
> machine.
> It displays the message "This screen saver requires OS X 10.14".

If the alert is that specific, it sounds like your bundle has an Info.plist key 
specifying that it requires 10.14.
Otherwise you'd get a more generic alert about "failed to load" or "fatal 
exception" or something…

—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: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

> On Oct 10, 2019, at 6:18 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> Just a guess but perhaps management had an awakening when they found the time 
> and effort expended to write the next even better version of Finder in Carbon 
> was substantially more difficult and costly that the prior Cocoa version.

The only Cocoa—>Carbon Finder transition I know of was before 10.0 shipped. The 
development versions had a NeXT file manager with a Mac UI skin, but before 
release that was replaced with a Carbon-ized port of (a subset of) the MacOS 9 
Finder. That Finder lived on for a few years before being replaced by a new 
rewritten Cocoa version.

—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: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 9, 2019, at 11:39 AM, Aandi Inston  wrote:
> 
> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get a 
> compile-time warning.

Only if you don't turn on -Werror, which I really, really recommend everyone 
do. Calling a method that a class isn't declared as implementing is a fairly 
common mistake, and warnings are way too easy to overlook.

In this situation, you get around the warning/error by declaring the method 
yourself in a category on the framework class.

> * I add a check for actual OS version, so I am very sure not try to call  
> [NSApplication doUsefulThing] 
> unless the OS is 10.15 or later.
> * But what happens if it runs in 10.15? Does it actually do the useful thing?

The method will be called, yes. I can't think of any particular reason it 
wouldn't work. 

—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: Thoughts on Cocoa source code

[Jens Alfke via Cocoa-dev]

> On Oct 9, 2019, at 10:19 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Why is Cocoa source code hidden?

So, take this as opinions of someone who worked at Apple, on [among other 
things] Mac OS X apps from 2000-2007.

(a) It's part of Apple's crown jewels and seen as a competitive advantage.
(b) It calls all sorts of internal APIs of lower-level components like the 
WindowServer, and Apple doesn't want to expose those APIs because they're 
undocumented, easily misused, hard to support, subject to change at any moment, 
etc.
(c) If developers look at the source code they'll be tempted to make use of 
undocumented behaviors, private methods, etc. which makes their apps much more 
likely to break in future OS versions. (This already does happen, to an extent, 
but with source code it would be much more pervasive, given the dynamic nature 
of Obj-C and how easy it is to call internal methods or even patch system 
classes.)
(d) Internal source code tends to have comments and identifiers that refer to 
internal code names, canceled projects, and other stuff that shouldn't be made 
public. Sanitizing this is a pain.
(e) Apple obviously works on lots of features that remain secret for months or 
years; these would all have to be kept in private branches, causing all sorts 
of merging/rebasing headaches.
(d) It takes quite a lot of effort to maintain a large open source project. 
It's not just dumping the source to Github.

> Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.

You don't want to use the _implementation_ details! Those can and do change 
completely over time — I know NSView has been redesigned/reimplemented at least 
twice since 2000 — so making use of them on OS version N could cause your app 
to break in version N+1. You want to know the details of the (defined) 
_behaviors_. That means better documentation. I agree that Apple could improve 
here.

> When debugging, the stack trace inside Cocoa was just a bunch of
> rarely-helpful Assembly. No way to set breakpoints inside Cocoa classes

That's not true; you can use symbolic breakpoints to break on any Objective-C 
method, or any C function that has a visible symbol.

> I personally learned C++ while using the PowerPlant library from Metrowerks. 

The difference is that PP is code that you link statically into your app. It 
doesn't change versions unless you explicitly update it. Cocoa is part of the 
OS, and changes one very OS release. Binary compatibility is super important to 
Apple, so Cocoa being a "black box" is actually a feature, not a bug.

—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: iOS play microphone to headphones

[Jens Alfke via Cocoa-dev]

> On Oct 8, 2019, at 10:06 AM, Alex Zavatone  wrote:
> 
> Doesn’t the user have to select the output device?

No, that's just the default. If you use audio APIs you can choose to direct 
output to any connected device.

—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: iOS play microphone to headphones

[Jens Alfke via Cocoa-dev]

> On Oct 6, 2019, at 1:07 PM, Eric Dolecki via Cocoa-dev 
>  wrote:
> 
> Quick Swift question. Is it fairly easy to take audio and play it to 
> headphones (not a recording) and be able to turn the microphone on/off? I’m 
> not interested in doing any analysis, just turning outside audio on/off.

That's an audio question, not a Swift question. And audio stuff is rarely 
straightforward.

I don't think AVFoundation covers 'live' stuff like this — it's more about 
recording and playback — so you're probably looking at the CoreAudio layer, 
which is a fairly gnarly C API with a lot of complex C data structures. I 
wouldn't think writing Swift glue for that would be easy at all :(

[Disclaimer: I haven't done any audio programming in a few years, so I may not 
know about some wonderful new Swift-level audio API that makes this easy.]

—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: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

> On Oct 4, 2019, at 12:41 PM, Lars C. Hassing via Cocoa-dev 
>  wrote:
> 
>   "Apple is committed to the HIViews, Carbon events, and nib files for Carbon 
> implementations of the user interface.
>All new controls and other features will be based on HIView.
>If you want your application to take advantage of the latest features, you 
> need to adopt the modern HIToolbox.”

If you look at the wording, this was telling Carbon developers they needed to 
update to HIViews, Carbon events and nib files. Not telling developers Apple 
was committed to Carbon forever.

And this was 15 years ago. A few years later (still over 10 years ago) Apple 
deprecated HIToolbox and it was pretty clear that Cocoa was the way forward.

—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: Thoughts on Cocoa

[Jens Alfke via Cocoa-dev]

> On Oct 2, 2019, at 10:14 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> For
> anyone smaller, it's hard to justify the constant need to rewrite code just
> to stay in the same place. Return on investment is just not there.  Seems
> like each new update is more difficult.

The people I hear complaining about this are those who, like you, didn't move 
to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac 
OS X shipped in March 2001, but even though it wasn't yet formally deprecated, 
it was clear it would be. The Carbon UI frameworks were deprecated circa, um, 
2006(?). QuickTime has been deprecated nearly as long. 64-bit systems shipped 
in the mid-2000s, even before the x86 transition, and it was obvious then that 
32-bit would eventually go away.

Eighteen years is _forever_ in the tech industry. At the time Cocoa was 
introduced, the Mac itself hadn't even been around that long!

It sounds like keeping an app limping along on 30-year-old APIs, and then 
suddenly trying to move it forwards all at once, is a bad idea. By comparison, 
keeping a Cocoa app up to date isn't that big a deal. I was maintaining Cocoa 
apps during the 64-bit, x86 and ARC transitions and had to make very few code 
changes. I've been out of the UI world for about 8 years, and there have 
definitely been significant changes in areas like view layout and document 
handling, but adapting to those isn't rocket science.

Yes, Microsoft is rather fanatical about compatibility. But that's part of what 
lost them their lead after the '90s: the amount of development resources needed 
to keep everything working exactly the same, and the difficulty of making 
forward progress without breaking any apps.

—Jens

* Yes it was. I was working at Apple and involved in the Carbon transition 
during 1999-2000.
___

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: Thoughts on ARC

[Jens Alfke via Cocoa-dev]

—Jens 

> On Oct 1, 2019, at 2:50 PM, Sam Ryan  wrote:
> 
> In fact those applications are forced upon the user in a way that I've never 
> seen before, as if they are core system components.

You mean pre-installed? There have always been plenty of bundled apps like 
Mail, Calendar, Chess, etc. The specifics have varied from release to release, 
of course.

—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: Thoughts on ARC

[Jens Alfke via Cocoa-dev]

> On Sep 30, 2019, at 4:57 PM, Sam Ryan  wrote:
> 
> I tried a completely new approach - Electron. I have found Electron to be 
> surprisingly quick to prototype, easy to bridge to c++, and is cross platform 
> (non mobile at least). I would not have recommended a non-native approach 
> until recently, but for what it is worth, I've come to realise this is one of 
> the better options available these days. YMMV. 

If you don't mind coding in JavaScript, don't care about Mac UI guidelines, and 
aren't shy about shipping a 200MB+ app that has an entire freakin' web browser 
embedded in it…

(Sorry for the grumpiness. I'm just sick of all the "Mac apps" that are just 
Electron-based web pages, e.g. Slack.)

—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: Thoughts on ARC

[Jens Alfke via Cocoa-dev]

> On Sep 30, 2019, at 8:16 AM, Robert Walsh via Cocoa-dev 
>  wrote:
> 
> however, to use it to do anything other than building a desktop or IOS GUI 
> application seems to result in code with messy syntax and what seem to me to 
> be hacks in order to bridge between NS* and CG* code.  (Lots of casts and 
> strange machinations for massaging pointers.)

This is true when calling C code from any language that isn't based on C :) 
Bridging between different languages is not a simple thing (I've done a lot of 
it…) Take a look at how you call C code from Rust, Go, Java,Python, etc.; it's 
at least as complex.

> Also, as you've said Swift makes cross-platform development nearly impossible 
> because, even though Swift itself is available on other platforms, the 
> pre-built components that prevent the developer from having to reinvent every 
> wheel from scratch are not. 

This is true, but getting less so. There's pretty good support for server-side 
Swift now, apparently.

Both of these are complaints about the immaturity of the Swift libraries, not 
about the language itself, and the good thing is that libraries are much 
easier/faster to build than languages.

—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: Thoughts on ARC

[Jens Alfke via Cocoa-dev]

> On Sep 27, 2019, at 9:20 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> What I wish Apple would do is release a cross platform Objective-C (and 
> Swift) solution. ...
> The Mac vs Windows war is over and long gone so why doesn’t Apple help out 
> the small developer and release a cross platform solution.

[OT]

I was typing a lengthy answer, but it occurred to me it's basically the same 
reason why Apple didn't release macOS for generic PCs ('hackintoshes') and in 
fact actively made it difficult for anyone to port macOS. It's because it would 
damage or tank their hardware business. To a lesser degree, if it's just apps 
being ported and not the whole OS, but still significant I think.

Porting your software crown jewels to run on commodity PC hardware is something 
only a failing company does, when it's throwing its own hardware business 
overboard. Consider NeXT and Be. (And I believe Amiga was planning something 
similar before they went under.)

Anyway, these days Windows is only for cash registers, accountants, and 
basement-dwelling hardcore gamers. ;-)

—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: Xcode 11 can't make an objective-C subclass any more?

[Jens Alfke via Cocoa-dev]

> On Sep 23, 2019, at 2:19 PM, James Walker via Cocoa-dev 
>  wrote:
> 
> Am I losing my mind, or is there no longer a good way to create a new 
> Objective-C subclass?  If I go to create a new Objective-C file, I am offered 
> the file type options: Empty File, Category, Protocol, Extension.  No 
> subclass.

Choose "Cocoa Class" in the first page of the assistant, not "Objective-C" file.
AFAIK it's always been like this…

—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: Why is / a metachar in regular expressions ?

[Jens Alfke via Cocoa-dev]

> On Sep 18, 2019, at 1:45 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I don't see why / is a meta character.
> It does not appear anywhere else in the documentation as metacharacter.

In some languages "/" is used as the delimiter to begin/end a regular 
expression, for example in sed where the substitution command is "s/old/new/".

So perhaps the underlying regex parser ignores "/" characters at the start/end 
of the regex unless they're quoted?

—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: 10.15 command line tools headers missing

[Jens Alfke via Cocoa-dev]

> On Sep 13, 2019, at 1:32 AM, Mark Allan via Cocoa-dev 
>  wrote:
> 
> I was initially reluctant to post this here because of NDA concerns

No worries, there hasn't been a F*cking NDA for years now. You can talk about 
beta Xcode builds in public.

> They've pulled the same trick again with 10.15 but this time, the installer 
> for the headers is also missing meaning I'm unable to compile 3rd party 
> software using the command line tools because of missing headers like zlib 
> and libxml2.

That's the first I've heard of this — I've had Xcode 11 for months and I build 
3rd party software with CLI tools all the time. And I assume lots of other 
people do too, otherwise HomeBrew would be pretty broken :)

The SDK headers aren't installed in /usr/include or /System/Library/Frameworks, 
but Clang's default header search path is pre-configured to include the 
equivalent dirs in the SDK.

—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: boundingRectWithSize gives wrong size

[Jens Alfke via Cocoa-dev]

> On Sep 10, 2019, at 9:54 AM, Gabriel Zachmann  wrote:
> 
> The excess width is sometimes more, sometimes a bit less, I could not find a 
> pattern.
> I guess , it has something to do with the actual glyphs in the string.

How much bigger is it? By a fraction of a character width? Or is it more than 
that? The right edge of the rectangle is probably not based on the actual glyph 
outline, but on the character's advance width. These can be quite different, 
especially in italics or if there are swashes.

> In my case, mesg_string is (usually) two lines of text (one string with \n 
> somewhere in the middle), 

Why not measure the two lines separately, since you said single-line text works 
correctly?

—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: boundingRectWithSize gives wrong size

[Jens Alfke via Cocoa-dev]

> On Aug 28, 2019, at 12:33 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
>   NSRect string_rect = CGRectIntegral( [mesg_string boundingRectWithSize: 
> drawRect_.size

What is drawRect_ set to when this is called?

It's been a while since I used this, but IIRC the output width will be the same 
as the input, with the height increased to account for the number of lines the 
string is broken into.

With NSStringDrawingUsesLineFragmentOrigin, if the text is broken into lines, 
it's not going to tell you the exact pixel width of the widest line.

In single-line mode (without NSStringDrawingUsesLineFragmentOrigin) I believe 
you do get the exact dimensions of the single line of text.

—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: Cocoa-dev Digest, Vol 16, Issue 72

[Jens Alfke via Cocoa-dev]

> On Aug 27, 2019, at 7:21 PM, Turtle Creek Software  
> wrote:
> 
> What I can't find is where the __bridge cast should go. The compiler 
> complains at all locations.
> The app runs the same, but will ARC be OK without it?

You shouldn't need to use __bridge at all, since you're no longer casting back 
and forth between Obj-C references and void*.

—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: Cocoa-dev Digest, Vol 16, Issue 72

[Jens Alfke via Cocoa-dev]

> On Aug 27, 2019, at 12:35 PM, Turtle Creek Software  
> wrote:
> 
> We are happy with the lifetime management in our C++ classes. 

You're having mysterious ref-counting bugs, so the fact that you're storing 
Obj-C references as void* sets off alarm bells.

> And C++ keeps improving.  ARC doesn't go there and that is fine.

Actually with Obj-C++ you get the best of both, so it's not either/or. And it 
would let you stop lying to the compiler, which would make your code more 
reliable and readable.

—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: Cocoa-dev Digest, Vol 16, Issue 72

[Jens Alfke via Cocoa-dev]

> On Aug 26, 2019, at 6:22 PM, Turtle Creek Software  
> wrote:
> 
> There are links between each Cocoa control class and its matching C++ control 
> (which also owns a native MFC control).  
> Also links between the view and our C++ controller, to load window layouts 
> and set up the control links.
> A couple utility links for showing progress bars, log window, etc.

Ah, OK. Your C++ code goes higher up the stack than I thought. (It sounds like 
using Qt would have been a good idea, but it's probably much too late to 
rethink that now.)

My suggestion is simply to compile all your C++ code as Objective-C++. In your 
project settings just tell Xcode to map the ".cpp" suffix to Objective-C++ 
instead of C++.

Then you can refer to Cocoa classes by their regular names in the C++ code, 
just as if you were writing Objective-C. ARC will automatically manage their 
reference-counting. If you have an NSButton* data member in a C++ class, the 
compiler will insert retain/release when it's assigned, and will add a -release 
call to your destructor. (Just make sure to initialize it to nil in its 
declaration!)

This way you aren't fooling the compiler, and it can do the right thing with 
reference-counts.

For x-plat compatibility, you can either #ifdef out the places those are 
referred to, or conditionally declare those class names as bogus C++ classes:

#ifndef __APPLE__
namespace cocoa {
class NSButton;
class NSWindow;
…
}
#endif

—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: Recommendations for cross platform library/framework

[Jens Alfke via Cocoa-dev]

> On Aug 26, 2019, at 4:41 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> I'd prefer avoiding C++ if possible.

I had a similar dilemma in 2015 but went with C++, despite earlier bad 
experiences with it. I've been happy with my choice; C++11 improved the 
language quite a lot and C++17 even further. I resist the urge to do crazy 
things with templates, and built some of my own infrastructure like ref-counted 
objects instead of using STL's.

> My first choice would have been using
> Go which can compile to .so shared objects but Xcode cannot use those
> without some bridge written in C.

I spent several years coding in Go. It's a nice language on its own, but its 
runtime does not play well with others. Go's roots are in a completely 
nonstandard OS (Plan9) and it shows. Go has its own function-call ABI, its own 
stack management, its own GC heap. This means it's impractical to add a Go 
library to a non-Go app (you have to instead let Go own the process and then 
load & call into non-Go code); and other developer tools like debuggers and 
crash analyzers are useless with Go code because they don't understand its 
stack frames.

(Disclaimer: I've been away from the Go community for a few years, so some of 
the above may have been resolved, but I doubt it since the custom runtime is 
key to the way Go works, i.e. supporting zillions of threads.)

> I've read Rust can compile to a dylib for Xcode.

I have not used Rust, though I've read a fair bit about it. It looks a lot more 
amenable for use in an app, since its runtime is lighter and its code 
generation is done by LLVM. The downside is that (according to many) Rust 
programming has a significant learning curve because of its memory-ownership 
rules.

And BTW: I don't know if there's been any progress on running Swift on Windows? 
It's pretty solid on Linux these days.

—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: Cocoa-dev Digest, Vol 16, Issue 72

[Jens Alfke via Cocoa-dev]

> On Aug 26, 2019, at 1:15 PM, Turtle Creek Software  
> wrote:
> 
> Our C++ is cross-platform.  More importantly, we have a LOT of accounting and 
> business logic in C++.
> To rewrite and test it would be 5 or 10 programmer-years.

I can understand the model and some of the controller logic being 
cross-platform, but why do you need the cross-platform code to have references 
to Obj-C classes? It's a cleaner separation to have the GUI-related code be in 
Mac-specific Obj-C++ classes that can refer directly to Cocoa.

> We never found any way to have Obj-C members in C++ header files, except as 
> void *.

Again, why does cross-platform code need to have references to 
platform-specific view/controller types?

—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: Cocoa-dev Digest, Vol 16, Issue 72

[Jens Alfke via Cocoa-dev]

> On Aug 25, 2019, at 5:49 PM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> No use of NSBridgingRetain or Release at all.  Is that necessary under ARC?

Those functions are only for casting CoreFoundation types to/from Obj-C.

> The void pointers are mostly to text fields and controls, plus the app
> delegate
> and one view.  None of those have had lifetime problems.  We mostly just
> access them and have them do one thing.

Unless your C++ code is cross-platform, it's better to use Obj-C types in it 
instead of casting them to void*. (Change the source file suffix to ".mm" if 
you haven't already.) Then ARC will manage them properly.

—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: ARC

[Jens Alfke via Cocoa-dev]

> On Aug 24, 2019, at 4:46 AM, Turtle Creek Software  
> wrote:
> 
> Our app delegate class is not deallocated.  The window controller is 
> deallocated
> despite the member reference there.

That should not be possible. Could you paste the exact line of code that 
declares the window-controller reference in the app delegate?

Have you verified that, at the point when the controller is dealloced, the 
reference in the app delegate is still non-nil? (I sometimes find it useful to 
set a breakpoint in the dealloc method, in weird cases like this.)

Do you have any remaining code that messes with ref-counting, I.e. by using 
CFRetain/Release on Obj-C objects?

—Jens

(And let me chime in that ARC is an excellent feature. Cocoa used to have 
‘true’ garbage collection as an option, but it was rarely used on Mac due to 
memory and performance impact, and never implemented on iOS for that reason. 
ARC works much better. Swift memory management is based on ARC, so it’s 
definitely the way of the future.)
___

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

[Jens Alfke via Cocoa-dev]

> On Aug 23, 2019, at 2:17 PM, Casey McDermott via Cocoa-dev 
>  wrote:
> 
> After we finished, the controller for our main window started being 
> deallocated some random time after launch.
> Apparently the erroneous strong references were keeping it alive.

AppKit delegates, like NSWindow.delegate, are unsafe-unretained references; 
this might be giving you trouble.

> We allocate the controller in our app delegate class. It's a member but 
> apparently that is not a 
> strong enough reference, so the controller is released at the end of the 
> scope.

A member variable is a strong reference by default, so that should suffice to 
keep it alive. Is your app delegate itself being dealloced?

—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: Is the list alive?

[Jens Alfke via Cocoa-dev]

> On May 29, 2019, at 7:22 AM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> Internally at Apple I would bet that most developers get their questions 
> answered by asking another developer.

Back when I worked at Apple (1998-2007) there were internal mailing lists much 
like these — I learned a lot and shared a lot on macosx-dev-internal. But yes, 
I think lists.apple.com  is only still alive because 
nobody at Apple can locate the Power Mac G4 that runs it, to shut it down. ;-)

> I need to take a look at co...@apple-dev.groups.io 
> . It looks interesting.

I started that list, and several others. You can see all the lists at 
https://apple-dev.groups.io/g/main  . The 
xcode list there is pretty lively too.

It’s easy to create more, if someone has another topic they think deserves a 
list of its own.

—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