Closed paperlib closed 7 years ago
I use the current code daily, Im sure you are right. Could you copy paste the code that breaks, then ill confirm and merge.
The test code where you would get the error. And what file event that produced the error. Did you remove file or add or etc?
Thx btw.
hi Eon,
The small/simple test app was certainly too simple, as I mindlessly placed all of the sample code - including the reference to FileWatcher (!) - within the applicationDidFinishLaunching
like so:
func applicationDidFinishLaunching(_ aNotification: Notification) {
let filewatcher = FileWatcher(["/opt/files"])
filewatcher.event = { (event) -> Void in print(event.description) }
filewatcher.start()
}
Obviously... by the time applicationDidFinishLaunching
had done it's job and the app started getting file events, any reference to filewatcher
was long gone - hence the crashes.
Making filewatcher
a property of the AppDelegate
class (moving it directly in the scope of AppDelegate
outside of applicationDidFinishLaunching
) solved the problem.
So I will cancel/close the request as it's not needed (problem was with my sample.) Apologizes for the noise... Thanks Stéphane
Not at all. yes: ⚠️️-the fileWatcher instance must be scoped to your class ⚠️️
var fileWatcher = FileWatcher(["~/Desktop/test/".tildePath])/*<---the fileWatcher instance must be scoped to your class*/
fileWatcher!.event = { [weak self] event in//<--The weak self part enables you to interact with your app
Swift.print(self?.someVariable)//Outputs: a variable in your current class
Swift.print(event.description)//Outputs: a description of the file change
}
Your PR gives insight though. If one can avoid using a class scoped ref that would make FileWatcher easier to use.
@paperlib, Are you on: http://swift-lang.schwa.io/ ?
wasn't, but now I am!
When testing FlieWatcher in a small macOS (Xcode 8 / Swift 3 / Storyboards) application, it would crash the moment the eventCallback was triggered (unable to retrieve the contextInfo passed to the callback)