Xojo System.Log

Does System.Log work in 2019r1.1 on MacOS? I can’t seem to find anything in Console.app. Is it a security thing in Catalina maybe?

Wondering what the best way is for my program to log in a way that slows down the program as little as possible and will send logging data as long as possible in the case of a crash. I feel like opening a text file, appending, closing might be slow as the data I’d like to log could be flying in at many per ms. I’d also not like for the program to crash in the middle of writing the log file before it gets a chance to close and leaving part of the messages behind.

it more or less does but Console is kind of stupid
if you dont search for you app name in the search field then it appears nothing shows
when you do you should see some, if not all, log messages

with this code


I see

default	15:20:59.257740-0600	My Application.debug	SignalReady: pid=57001 asn=0x0-0x390c909
default	15:20:59.258117-0600	My Application.debug	SIGNAL: pid=57001 asn=0x0x-0x59820297
default	15:20:59.265208-0600	tccd	-[TCCDAccessIdentity staticCode]: static code for: identifier com.mycompany.myapp, type: 0: 0x7fdd2ec315c0 at /var/folders/3t/wyqsbmsj4bbf_z_wdrjnp0zw0000gn/T/TemporaryItems/My Application.debug.app
default	15:20:59.273988-0600	My Application.debug	NSApp cache appearance:
-NSRequiresAquaSystemAppearance: 0
-appearance: (null)
-effectiveAppearance: <NSCompositeAppearance: 0x600001661280
    "<NSDarkAquaAppearance: 0x600001674b80>",
    "<NSSystemAppearance: 0x600001675380>"
default	15:20:59.299279-0600	My Application.debug	System.Log(System.LogLevelAlert
default	15:20:59.299314-0600	My Application.debug	System.Log(System.LogLevelCritical
default	15:20:59.299355-0600	My Application.debug	System.Log(System.LogLevelEmergency
default	15:20:59.299371-0600	My Application.debug	System.Log(System.LogLevelError
default	15:20:59.299407-0600	My Application.debug	System.Log(System.LogLevelNotice
default	15:20:59.299454-0600	My Application.debug	System.Log(System.LogLevelWarning

Thanks. Doesn’t seem to work for me, and not really keen on the way it works anyway. I’ll just try and write to a file and flush with a timer. Hopefully that works well enough.

Console shows you messages from when console was opened. If you want to see messages from before, you have to use the Terminal or you can try my App Report https://www.ohanaware.com/appreport/

Don’t do this manually. textoutputstream.append leaks on Catalina, eventually filling up the allotted amount of files an application is allowed “open”, and thus preventing your application from opening or saving any more files.

Which is why I started the App Report project.

My app writes a certain amount of data to a file I call “session log”. If there isn’t too much data the speed is okay.

For diagnosing problems the app has 2 options to write more data with the warning “makes the app slower”. W.hen the file gets larger than 1 MB I simply make a new one.

There’s certainly uses for it. In an ideal world, Apple would let our apps dig into the system and to recall any data our apps has written there. However for “Security” Sandboxed apps are prohibited from accessing the log data, not to mention that it is incredibly slow.

I filed a feature request with Apple to allow this, but so far no response and I guess like any FR I make for security, it’ll get ignored or shot down.

If you’re outside of the App Store, it’s totally possible for an application to do a log dump of everything the Unified Apple Logs have collected on it. I may even see if I can utilize this in a future AW version.

I don’t use append. Just flush. If flush is used, the data seems to be written to the file, and even if it doesn’t get closed it’s still seems to be fine. I’ve looked at the file during the middle of the program (before it’s closed) and it’s all valid. My guess is that a text file is maybe tolerant of not being closed?

unless a file is opened fo exclusive access, which any file can be, other programs can read it as well

the command “tail” in a terminal is very handy for watching log file entries

Not sure if you were replying to my comment? If so, my reference to “tolerance” was that it seems that closing the file isn’t necessary for it to be valid and readable. As opposed to some other binary files that if they are not closed properly, they end up corrupted. (I’ve seen many music files (esp. mp3) have this issue).
I do close the file at the end of program, but it’s nice to know that if the program crashes for some reason, the file is still readable. Maybe all the open/append/write/close steps are not really necessary for a simple text-based log file?

text files can be forgiving this way
binary files can be as well - just that usually if they are incompletely written then the software that reads these files has issues because the file is incomplete

I would expect that as long as you flush the output stream (text or binary) that you should be pretty safe and the data will be “safe” and readable

Note that Apples system log facility caches things and does not write everything to disk :slight_smile:

The system stores all messages in memory initially, and it writes messages with more severe log levels to disk.
This may also be what you’re not finding all your log messages unless console is running and filtering for those messages (Yet another case of Apple trying to be helpful and making this more a pain in the ass in the process)

What I cant say is whether Xojo’s System.debuglog and System.log call into this newer os_log api or use the older one. That may play into it as well

This may be useful as well on macOS as you can, on a per application basis, alter the logging behaviour