Thank you Quinn. I always appreciate your help. It's a pity that sfltool doesn't allow removing all traces of a given job to get around these issues, but I take your point about testing on a clean VM. Thanks again

Thanks Quinn I have worked around this by removing the NSMenu.delegate assignment from the .xib and called myMenu.delegate = self after return from the NSAlert.runModal() call.

To help clarify the above, the menuWillOpen() function is declared as an AppDelegate:NSMenuDelegate extension. extension AppDelegate: NSMenuDelegate { func menuWillOpen(_ menu: NSMenu) { if menu == myMenu { // enable/disable menu items } } } @NSApplicationMain class AppDelegate: NSObject, NSApplicationDelegate { @IBOutlet weak var myMenu: NSMenu! // NSApplicationDelegate functions }

Sorry for the noise. I had forgotten to add '.plist' to the id when running launchctl unload. All fixed now. The root process is started from AuthorizationExecuteWithPrivileges and then a setuid(0) before running launchctl. I know that's frowned upon but hopefully by the time the deprecated call disappears any affected users will have already updated :)

I had a similar experience, although I did not see the dialog you posted. In my case it was reported as an ssh failure. Like you, I could do a git push from the command line but Xcode was failing. To get it working I edited ~/.ssh/known_hosts and deleted all entries to do with my git server. I then manually logged into the git server (via ssh) and when prompted accepted the connection, adding the keys to known_hosts. Following that Xcode "push" was working again. I have no idea as to why the failure occurred but I am happy that it is working now.

getifaddrs() will return the IPv4 & IPv6 addresses of each interface. This in most cases, especially for IPv4, will be an address on the users local network. If you're after the users public IP address you will have to use some other method, such as visiting one of the many sites on the internet, via an http(s) request, that will reply with the connecting address.

This problem appears to be fixed in XCode 16 Beta 2. I don't see any mention of the problem in the release notes but I have successfully compiled and run an application on an intel Mac with macOS Sonoma 14.5 and Xcode 16 Beta 2.

I am seeing this same crash when running XCode 16 on a macOS 14.5 (sonoma) host. The minimum deployment for the project is macOS 10.13. There is nothing in the Xcode 16 release notes about macOS 13.0 being a required minimum deployment. so I don't think that is a solution.

Look in the 'More downloads' tab https://download.developer.apple.com/Developer_Tools/Xcode_14.3.1/Xcode_14.3.1.xip

And solved (I think ...) #if swift(>=5.9) self.clipsToBounds = true #endif

@eskimo Sorry to ressurect an old thread. I was just faced with this very issue trying to run a shell script using Process(). My program was waiting 10 seconds for enough data to fill the buffer before the 1 second updates from the script were presented to my read handler. On reading man setbuf, I saw a reference to setting the environment variable STDBUF. Inserting export STDBUF="U" into the script seems to have solved the problem and my program now receives each message as it is output from the shell script. I was unable to find reference to this environment variable anywhere else and am just asking for reassurance that it won't suddenly disappear.

Fixed with Xcode 14.3 beta 3

Submitted FB12051702 with a sample project demonstrating the failure.

Instead of looking to call Swift from C++ you should probably look at it the other way round. Use Swift as the main language for your development - it integrates beautifully with Interface Builder and is ideally suited for building a gui. You can then make calls to C/C++/Obj-C using the Swift bridging interfaces. Admittedly there is a bit to learn but I think you'll find Swift to be quite easy to become familiar with. I have found C/C++ to be very useful in Swift applications for dealing with Posix/System interfaces, then passing results back to Swift either as arguments or via closure/callbacks.

Not a commandline solution but whatroute (https://whatroute.net) will perform tcp traceroute.