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

Re: Cannot include Carbon on Mojave

[Jens Alfke]

> On May 15, 2019, at 8:07 AM, Glenn L. Austin  wrote:
> 
> Actually, the screw ups are on those software developers who write their code 
> based upon SDK behavior, not documentation. Yes, Apple sometimes makes 
> mistakes, but more often the "mistake" is that Apple fixed a bug (isn't that 
> what an "unintended side-effect" is?) that a software developer depended upon 
> to "save time" or "do something clever."

Audio software seems more prone to OS compatibility issues than regular stuff. 
I think that’s because it’s dependent on a lot of tricky things like 
multithreading with real-time requirements (no dropouts!), USB drivers, etc. 
There’s also the way that Apple’s audio APIs (esp the lower level ones like 
AudioUnits) are very complex and under-documented.

I’ve been building an audio app off and on since 2005(!) that I use myself. 
I’ve always wanted to release it commercially, but it’s never quite stable 
enough, and OS upgrades often seem to destabilize it.

That said, I think Vojtek is speaking for a minority of audio users. There are 
certainly many musicians working with the latest versions of Ableton Live, 
Reaktor, Reason, etc.

—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: Cannot include Carbon on Mojave

[Jens Alfke]

> On May 14, 2019, at 2:40 PM, Vojtěch Meluzín  
> wrote:
> 
> Hey folks, that's to you all. It's all the missing 32-bit support now...
> Need to revert to XCode 9, forever... The audio community just needs and
> will need 32-bit support, no matter what Apple thinks.


Well, I’m in the audio community*, and I don’t need 32-bit support. Why is it 
necessary, except for supporting very old computers (Apple hasn’t shipped a 
32-bit CPU since 2006**) or supporting badly-written source code that doesn’t 
work in 64-bit?

—Jens

* I own Ableton, Logic, a bunch of hardware synths, and a rack of Eurorack 
modules.
** According to 
https://apple.stackexchange.com/questions/99640/how-old-are-macs-that-cannot-run-64-bit-applications
 

 , a thread from 2015 that states "you can very confidently forget about 32bit 
if you're developing an application”.
___

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 troubles

[Jens Alfke]

> On May 14, 2019, at 3:39 AM, Peter Hudson  wrote:
> 
> xCode has just decided ( for the 20th time this week ) that I don’t deserve 
> any UI tools in Interface Builder - as in the panel on the right hand side of 
> the main window.  I have tried everything I can think of to try to get them 
> back - like restarting xCode, opening different files etc.

You mean that clicking the Show Inspectors button on the right end of the 
toolbar didn’t work, nor did Cmd-Opt-zero?

—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: Category errata in Objective-C

[Jens Alfke]

> On Mar 29, 2019, at 2:51 PM, Alex Zavatone  wrote:
> 
> Also, I seem to remember the esteemed Jens stating that as soon as a category 
> class is in your project, it applies to all objects instantiated from the 
> base class and we only had to do an import if we wanted to use the category 
> methods in the debugger.  Please correct me if I am wrong here.

No, you have to #import the header if you want to use the category methods in a 
source file.

At _compile_ time, when you call one of those methods the compiler needs to 
have seen a prior declaration of that method or it'll flag an error. Thus, you 
need to have #included the header file declaring the category. (The compiler 
_could_ go ahead and decide you know what's right, and just compile a call to 
that method anyway; back in the old days it used to, but that turned out to 
lead to lots of stupid runtime crashes caused by mistyped method names.)

At _runtime_, the category patches the class implementation when your app 
starts, so its methods are available everywhere.

—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: My eyes are failing me.

[Jens Alfke]

> On Feb 22, 2019, at 1:07 PM, Alex Zavatone  wrote:
> 
> It should not show the /api in the description of the URL if it is not going 
> to use it in any call using that URL.  

The .baseURL property returns the original URL with the /api path.

> It’s outright misleading and there is nothing in the class docs for NSURL or 
> in the header that indicate this is the intended behavior.

I agree it’s weird. I suspect it reflects an implementation where a relative 
URL is stored as the relative path plus a pointer to the base NSURL object … 
but that’s not really relevant to anyone using it.

It’s been this way forever, or at least since 2001. Feel free to file a Radar. 
But it’s just the .description, so if you ignore that property you’ll be OK.

—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: My eyes are failing me.

[Jens Alfke]

> On Feb 22, 2019, at 9:40 AM, Alex Zavatone  wrote:
> 
> The description is non standard and misleading and the /api string is 
> stripped from the URL that it indicates it will use in that URL.


You gave it an absolute path, “/login”. This has exactly the same meaning as an 
absolute filesystem path — if you’re in “/api” and type “cd /login”, you don’t 
end up in “/api/login”.

(Yes, I know, it’s a relative URL with an absolute path. URLs are weird due to 
the two-level namespace of domains and paths…)

—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: My eyes are failing me.

[Jens Alfke]

> On Feb 22, 2019, at 8:39 AM, Alex Zavatone  wrote:
> 
> self.loginURL = [NSURL URLWithString:@"/login" 
> relativeToURL:self.sharedData.webServicesURL]; // // WHY does this not work? 
> It does "/login -- https://qa-home.mrcooper.com/api 
> "

Because NSURL’s .description property has a stupid way of printing a relative 
URL.

The actual URL is correct, as you’ll see if you do something like `po 
self.loginURL.absoluteString`. It should return ` 
https://qa-home.mrcooper.com/login` .

Moral of the story: Always use .absoluteString to convert an NSURL to a string, 
never .description or something that calls it implicitly.

—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: Silly question on extending NSObject.

[Jens Alfke]

> On Feb 20, 2019, at 5:11 PM, Alex Zavatone  wrote:
> 
> Commenting out #import “NSObject+AutoDescribe.h” in the .pch does cause an 
> invalid selector build error if autoDescribe is used in any class file, but 
> you can enter it on an object from the debugger.

The warning/error is just because the compiler hasn’t seen that selector 
anywhere, so it doesn’t know it’s valid. You can fix it by #including the 
AutoDescribe header in that source file. Or create a prefix header and #include 
it there.

—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: Silly question on extending NSObject.

[Jens Alfke]

> On Feb 19, 2019, at 1:23 PM, Alex Zavatone  wrote:
> 
> In most Objective-C projects I add an autodescribe category on NSObject and 
> put the import for the category header into a .pch for the project so that it 
> will be available for every class in the project.
> This lets me dump an object’s properties and values at Will in the debugger.


I’m not sure what this does that the existing -description and 
-debugDescription methods don’t do?

> Is there a more modern way to do this than using a .pch?

You don’t need a PCH for this. If you declare the category in an @interface or 
@implementation that gets parsed as part of your target, it’ll exist. Same for 
the methods in the category. It doesn’t matter whether the interface is parsed 
in every source file or not.

—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: Questions regarding the sandbox in iOS

[Jens Alfke]

> On Feb 5, 2019, at 6:13 PM, Carl Hoefs  wrote:
> 
> Of NSHomeDirectory, NSDocumentDirectory, and NSLibraryDirectory, I'm 
> currently using NSDocumentLibrary for the scratch directory. I presume for 
> each of these areas, the storage is persistent across app invocations. Is 
> there a temporary area available for use? 

NSTemporaryDirectory?

It does matter which of these you use, because there are policies for their use 
that are checked during App Store review. I know that an app can be rejected if 
it puts things in Documents that are not related to user-visible data, or if it 
continually adds data to directories that are backed up to iCloud.

—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: Questions regarding the sandbox in iOS

[Jens Alfke]

> On Feb 5, 2019, at 9:25 AM, Carl Hoefs  wrote:
> 
> The reason for the specific sandbox questions is that my iOS app needs to 
> call 3rd-party functions, some of which create temp files "in place" - as if 
> they did an fopen("filename.ext","w"). Such temp files appear to be written 
> "nowhere"... 

You can set the current directory wherever you want, via the system call 
chdir(), before calling those functions. 

—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: NSImage to JPEG file?

[Jens Alfke]

> On Jan 16, 2019, at 9:59 AM, Carl Hoefs  
> wrote:
> 
> But all of that would come "for free" if NSImage inherited from NSData, no?

Well, that wouldn’t make sense, because an NSImage isn’t a piece of data. It 
can have multiple data representations (JPEG, PNG, PDF…) and it might not have 
any at all if it was created directly in-memory with a pixmap. It’s a thing 
that can create a data representation.

—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: NSImage to JPEG file?

[Jens Alfke]

> On Jan 16, 2019, at 8:32 AM, Carl Hoefs  
> wrote:
> 
> It was the NSData tie-in I didn't know. (I was expecting NSImage to have 
> innate export capabilities

That would be poor API design. If it had -writeToFile, then it would also need 
-writeToStream:, -writeToFileHandle:, -writeToFileDescriptor:, 
-writeToNSURLSessionDataDelegate:, etc.
Providing the data itself means you can then use existing APIs on other classes 
to put the data anywhere you want.

—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: NSImage to JPEG file?

[Jens Alfke]

It’s been a long time since I worked with NSImages, but it’s easy to get a JPEG 
representation using just plain AppKit. 

Just look through the representations for an NSBitmapImageRep, then call [rep 
representationUsingType: NSBitmapImageFileTypeJPEG options: 0].

—Jens

PS: _Please_ don’t reply to digests. It messes up the subject line and the 
message threading.
___

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 would a view be asked to draw after its window has been ordered out?

[Jens Alfke]

> On Dec 13, 2018, at 1:26 PM, James Walker  wrote:
> 
> The view was using a C++ object that had been destroyed during closing of my 
> document.  I'm afraid that if I start playing with the order of destruction, 
> I'm likely to break something else.  

An NSDocument won’t be dealloced until all of its windows have been closed and 
released.
It’s been many years since I used NSDocument, but it sounds like you shouldn’t 
be deleting this C++ object when the document is being closed; wait until it’s 
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: Custom NSButton image effects for pressed/disabled

[Jens Alfke]

> On Dec 11, 2018, at 5:03 PM, Lars C. Hassing  wrote:
> 
> If I assign an image to an NSButton it is displayed with nice pressed and 
> disabled effects.
> 
> In my custom NSButton, that should display image1+title+image2, I override 
> drawRect:, but how do I obtain the EXACT SAME system effects for the two 
> images?

Don’t override drawRect; you should use a custom NSButtonCell instead. (In 
general NSButton is just a wrapper around NSButtonCell.)

That itself may solve your problem. If not, you could work around it by 
creating a single NSImage (at runtime) with the two images and the title in it, 
and just setting that as the button’s image.

—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: Sharing Files Between My Apps via iCloud

[Jens Alfke]

> On Oct 26, 2018, at 3:43 AM, Uli Kusterer  
> wrote:
> 
> Many apps make that assumption about Dropbox as well, and it is dangerous. 

Yup. Case in point is the support forums for Scrivener (an excellent word 
processor for book-writing, which uses a bundle file format), where there are 
numerous complaints about the data-loss problems people have had with Dropbox 
sync. 

—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: C++ pointer to Cocoa object

[Jens Alfke]

> On Sep 7, 2018, at 10:46 AM, Casey McDermott  wrote:
> 
> Problem is, with ARC turned on, the pointer is never nil, so it crashes.  
> The void pointer somehow becomes an NSAtom instead of 0.

Something wrote to that pointer, then. If you initialize it to nullptr, it will 
stay that way. NSAtom is a red herring — probably the mCocoaPopupPtr was 
pointing to a valid object, but it got freed, and there is now (by chance) an 
NSAtom instance residing at that address.

The reason the object got freed is probably that your C++ pointer isn't known 
to ARC so it didn't bump the refcount of the object assigned to it. You'll need 
to use CFRetain/CFRelease to manually retain objects assigned to that pointer.

—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: Carbon -> Cocoa

[Jens Alfke]

> On Aug 22, 2018, at 10:40 AM, Alastair Houghton 
>  wrote:
> 
> Well, yes and no. If the network library works that way, it’ll fire its 
> callbacks on the background thread, which makes life awkward if you’re 
> interacting with the UI

Then you write glue around the callbacks that dispatches them on a selectable 
dispatch queue. (Which you'll want to do anyway, because who wants to work with 
C callbacks?)

> Much better to use a library that’s properly integrated with the native run 
> loop and that therefore doesn’t end up calling your code on a background 
> thread.

To be pedantic, both NSURLSession and Network.framework are based on dispatch 
queues, not runloops. They call delegate code on the dispatch queue assigned to 
the task.

Anyway, I agree with you that using a library integrated with OS facilities is 
better than one that isn't. But developers using non-HTTP protocols, or coding 
in C/C++, don't have that luxury … not until they can move up to iOS 12 / macOS 
10.14 as their deployment SDKs.  In my case that's probably about three years 
away. :(

—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: Carbon -> Cocoa

[Jens Alfke]

> On Aug 21, 2018, at 8:33 AM, Alastair Houghton  
> wrote:
> 
> So, for instance, it’s not so good on macOS or iOS if its event dispatcher is 
> based on select(), (e)poll() or kqueue() because what you really want on 
> macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, 
> you’ll end up having to use threading to run the network library’s event 
> loops on background threads, which for an async networking library kind of 
> defeats the point IMO.

It does mean you have to spin up one background thread to sit and wait for 
events; but that's not a big hardship. You still get the scalability benefits 
of event-driven I/O, vs. having to use one thread per socket the old-fashioned 
way.

(NSURLSession and Network.framework are doing the same thing under the hood, 
after all.)

—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: Carbon -> Cocoa

[Jens Alfke]

> On Aug 18, 2018, at 11:19 AM, Stephane Sudre  wrote:
> 
> It might be the new Carbon once:
> 
> - there is ABI stability in Swift. This could be not before late 2019.
> 
> - the new APIs are only available in Swift. Is Swift NIO a hint this
> is coming sooner than expected? 

By “NIO” do you mean the new Network.framework? They did only demo the Swift 
API at WWDC, but it has a full C API too. (Which makes sense, since part of its 
goal is to drag C developers away from the POSIX sockets API.)

> I don't know. I don't use networking frameworks.

You should consider adopting one at some point. There are several benefits they 
provide that aren’t available with POSIX APIs, like faster connection startup, 
and transparently switching between WiFi and cellular. (Stuart Cheshire’s 
various WWDC talks go into detail.)

—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: Carbon -> Cocoa

[Jens Alfke]

> On Aug 20, 2018, at 12:43 AM, Alastair Houghton 
>  wrote:
> 
> I’d tentatively suggest that it’s likely that Swift will develop some means 
> of interfacing more directly with C++ code in the future, which should make 
> this easier rather than harder.

There are tools like SWIG for generating inter-language glue code; I don’t know 
if it supports C++ and Swift, though…

—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: Carbon -> Cocoa

[Jens Alfke]

> On Aug 17, 2018, at 9:45 AM, Casey McDermott  wrote:
> 
> It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.  
> Throw in Swift and future APIs
> that are Swift-dominated, and it becomes harder.  How soon will it be 
> impossible?

Never. I can't think of a single (nontrivial) language that doesn't have a 
foreign-function mechanism to call into C code. It's vital to have this, since 
much of a higher-level language's runtime support code and libraries are 
written in lower-level languages.

Also, even if 'Marzipan' is released with the goal of eventually replacing 
AppKit (which is speculative), it will be in a similar position to Cocoa in 
2001 — regardless of how good it is, the apps that _must_ be kept running on 
the Mac, like Office, PhotoShop, Final Cut, Ableton Live, still use the old 
language/framework and won't be rewritten any time soon. That means Apple must 
keep supporting the old framework for years and years and years. (17 years and 
counting, in the case of Carbon…)

—Jens  [who worked in the OS team at Apple during the OS 9 / OS X transition]
___

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: Archiving a project

[Jens Alfke]

> On Aug 5, 2018, at 4:49 PM, Saagar Jha  wrote:
> 
> There used to be an Xcode mailing list, but it was shut down a while back. I 
> assume most of the usual traffic to that list has thoroughly dispersed 
> throughout the rest of the lists on this site, as well as help groups 
> elsewhere on the internet.

I run an unofficial Xcode mailing list at https://apple-dev.groups.io/g/xcode 
 , and a number of other lists with 
similar topics to the lists here; you can see them at 
https://apple-dev.groups.io/g/main  . They 
get a decent amount of traffic. I figured it was a good idea to have a listserv 
that isn't in danger of being shut down tomorrow…

(And yeah, there are Apple's official developer forums, which they would prefer 
we use, but like many people I dislike their usability.)

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

[Jens Alfke]

> On Jul 25, 2018, at 10:45 AM, Casey McDermott  wrote:
> 
> The goal is to auto-fill an account from what they type, and ignore typing if 
> not a match.

That sounds like the regular behavior of NSPopUpButton: after clicking to pop 
up the menu, you can type-select items from it. 

(Although it doesn't ignore mismatches, it just selects the closest item.)

—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: Lazy calculation of tooltip text

[Jens Alfke]

> On Jul 6, 2018, at 8:22 AM, Jonathan Taylor  
> wrote:
> 
> Any suggestions on how I might supply tooltip text dynamically, when the 
> tooltip is about to display?

@protocol NSViewToolTipOwner 
- (NSString *)view:(NSView *)view stringForToolTip:(NSToolTipTag)tag 
point:(NSPoint)point userData:(nullable void *)data;
@end

___

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