Re-working this part of my parser so it can be resumed after resolving a dependency is not trivial since the dependencies can occur at many different code paths. I might try doing a 2-pass processing where the first pass only extracts dependencies.
Post
Replies
Boosts
Views
Activity
Regarding programming errors, the documentation specifically states (emphasis mine):"The channel takes control of the specified file descriptor until the channel closes ... It is a programmer error for you to modify the file descriptor while the channel owns it."So this sounds like after I call channel.close() it is ok for me to close the underlying file descriptor. This is the scneario in which my cleanup handler is called. I close the channel, then I close the file descriptor, then my cleanup handler is enqueued. If I don't close the FD, I get no cleanup.Your point about DispatchIO code spiraling out of control is well noted. I'm not too far along on this part of the project, but so far everything has been working as I expected, except for the cleanup handlers, however if weird behavior like this keeps cropping up I'll be prepared to go with a different solution. The key feature that drove me to DispatchIO in the first place is large (100's of MB) asynchronous, cancellable, streaming read operations. I'm definitely open to other suggestions.
Well, my actual situation is more complicated. I'm creating mutiple channels from the same FD, and each channel has some channel-specific cleanup code that needs to run when it's finished. The final cleanup of the FD happens much later. This is not an insurmountable problem, obviously I could manually call the channel-specific cleanup code when I close the channel, however it would be a lot more convenient and better factored if it was encapsualted in the cleanupHandler and worked like the documentation says.
Thanks! I was not aware dispatch had man pages. That explained exactly what I was seeing with the completion handlers. I can't use them the way I wanted, but at least I know what's going on now.
Ok I had some more time to experiment. It looks like the package repository must have a branch called "master" for this to work. If the main branch in the package you're trying to import is called anything else, like "trunk" or "main" for example, adding the dependency will fail. This is particularly bad because creating a new package in Xcode (File -> New -> Swift Package...) creates a git repo with a branch called "main", not "master"!
Wondering the same thing. In particular there doesn't seem to be a way to place items in the toolbar area above a source list on macOS (like in Calendar for example).
Looks like just about anything inside a sheet on macOS doesn't layout correctly. For example:
.sheet(...) {
		 NavigationView {
Form {
Section() {
TextField("Name", text: $name)
}
Section(header: Text("Title")) {
TextField("Address", text: $address)
								}
			}
}.navigationTitle("New Item")
}
Looks great on iOS but on macOS has clipped controls, incorrect margines, sections running together with no/incorrect padding, etc.
I'm a swiftUI newbie, but so far my experience has been that your cross-platform swiftUI views will be full of
#if os(...)
And for modifiers, I guess you have to do something like this, which makes it even more annoying
/// Workaround since .collapsible isn't available on iOS and there's no way to #if out the modifier function directly
extension Section where Parent: View, Content: View, Footer: View {
func noCollapseIOSCompat() -> some View {
#if os(macOS)
return self.collapsible(false)
#else
return self
#endif
}
}
Using a file with 0700 permissions seems like the best I can do then. Thanks! That fits more easily into my existing design than adding a special install mode to the daemon.
I noticed the same issue in an ObjC app that has no swift (or swiftUI) at all so I don't think that's related. Xcode 12.2 beta, iOS/iPadOS 14.0
Sorry, here is an example. Paste this into a new macOS swiftUI project and do a live preview to see what I mean.
import SwiftUI
struct ContentView: View {
@State var isPopped = false
var body: some View {
Button("Popover") {
isPopped = true
}
.popover(isPresented: $isPopped, content: {
MyPopover()
})
.padding()
}
}
struct MyPopover: View {
@State var moreControls = false
var body: some View {
Form {
Text("Text")
Button("Toggle") {
withAnimation {
moreControls.toggle()
}
}
if moreControls {
Text("More Controls")
}
}
.padding()
}
}
I submitted a feedback request to have this added, because right now there doesn't seem to be a way to make Form() containing TextField() look right on macOS because of the missing labels. FB8636648. I suggest you submit a feedback request as well.
So I read through TN2265: Troubleshooting Push Notifications - https://developer.apple.com/library/archive/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG24 and it looks like the problem is that APSD never connects to the *development* iCloud environment on macOS because: I get neither the success nor the failure delegate callback when registering for remote notifications
apsctl status shows:
daemon status:																Running
certificate status:													 Provisioned, using existing certificate
app refresh activity:												 Yes
connection environment:											 development
	 courier status:														Not connected because there are no eligible topics
			enabled:																Yes
			stream connected:											 No
			connected to service:									 No
I'm guessing "there are no eligible topics" means "you are not running any apps that connect to the development environment", so perhaps the problem is that it's not noticing that I'm launching my app that wants the dev environment? I'm kinda stuck at this point though because I don't see any documentation on apsctl that would allow me to troubleshoot further.
I am having the same issue. iOS devices work fine, but macOS devices won't connect to the development push service. Bug report: FB8968738
Filed FB8968738, I'll post here again if anything comes of it.