AFAIK Xojo uses NSLog which may NOT write to a file
https://developer.apple.com/documentation/os/logging?language=objc
This doc also lists how to alter the behaviour of the system logger
I made a Feedback request (sorry, wrong 'puter) for Xojo to adopt the newer logging functions; I gave it a quick try, but couldn’t get it to work with Declares.
Ideally we should be using the Unified logging system, yes there’s a lot of CRAP in there, but it logs not only the messages that mean something to us (as developers) but most importantly NSInconsistencyExceptions which are incredibly common in the recent years. My understanding is when Apple changes an API, these exceptions are generated when you’re passing values for prior OS versions, not current. There’s no error displayed in the app, nor is the exception captured via Xojo. Suddenly everything on your window stops working, no indication as to why.
Only way to see these (currently) is to use the terminal and get the unified logging system to take a dump, sift out the useless crap and voila, there’s the exception message.
This is just one of the many things that I am working on at the moment.
1 Like
I started doing this last year; especially in circumstances when I just need to get an idea of what’s going on. I do still see value in this, especially if you’re logging actions taken on a specific document.
What I would suggest you consider; because I can confirm that using this approach does have an impact on performance, it to concatenate the log. Store the entries in memory for as long as you can, then write in one go. For some tasks, I don’t actually do any writing until the user sends me feedback or the application is switched away. For debugging a function on a users computer, I choose to write the values after a minimum period of time.
Feedback for Xojo to use the newer logging functions from macOS 10.12.
I purposely did not do this… If the app crashes prior to a write, then you lose the last X entries…
Agreed; you have to choose between bad and worse.
Using system.debugLog is going to give you both performance and ability to recover the log if the application crashes; but it comes with a cost of having to extract the log information and clean it all the useless crap.
The other option, I’ve been thinking about is using a block of shared memory to store the temporary log entries. This way should the app crash, and is re-opened, it knows it crashed because the memory is already allocated, and can then extract the last few entries.