By default, the string output of JSValue in JavaScriptCore printing (e.g. via my console.log) will produce a mere [object Object]. That’s not very helpful. It’s simple to pretty-print objects (if they are merely data-containers) via JSON:
I have been complaining on social media about the Xcode Console sticking to the bottom, and how I’d prefer a horizontal split etc. And there have been good suggestions to e.g. open a new Console tab or window. (Thanks Dominik Hauser for the tip!) That didn’t stick because I needed to adjust the Xcode behaviors and sometimes that didn’t compose well with what I’ve been doing.
I am not good at reading crash logs of my apps. Some errors are obvious, like index out of bounds exceptions. Others require actual symbolication of the crash log to reveal the symbol aka function name in the stack trace. You can do this in the command line and interactively explore the crash reasons like a caveperson.
By default, you cannot print to the Xcode console from within a JavaScriptCore-evaluated script. print, echo, console.log – nothing of the like is available. Caveman debugging is tremendously useful, though, so we all know that we want to print from the JavaScript we evaluat, right?
The past couple of days, I’ve been working on integration of an automatic crash reporter. Turns out that on some machines The Archive is crashing regularly during search, and I want to track this down. I need data by more than the most courageous users who can venture into the Console to track down crash report files and send them to me.
So I bit the bullet and began work on a server script that would accept crash report files and email them to me. I think that’s better than making users email me crash reports directly. Not everyone has Mail.app set up on her Mac, after all.
Just have a look at the code: Collecting .crash files and sending them over? Sounded simple enough! NetNewsWire even sports a very humble crash reporter UI, and automatically sending reports on the user’s behalf if the user choses to do so. The required Swift types are simple enough to integrate once you figure out where Brent put all the helper extensions :)
I cannot stress enough how amazing open source is. All this experience, assembled in publicly available code repositories for everyone to grab and use. This is crazy.
I am now rolling this out for my apps, starting with the WordCounter and The Archive on their respective “beta” update branches to see how it works in practice. The Swift code is simple and I trust it doing its job. But the server script, well, it needs to be battle-tested now!
I’m going to add public-key encryption of messages and/or some sort of authentication to prevent malicious attackers from spamming me with emails that, well … I send to myself.
This time, I don’t want to find out if the app is compiled as debug/release mode; I want to find out if the debugger is attached. I found an Objective-C answer on StackOverflow which is based on HockeyApp-iOS.
I utilize NSResponder actions in TableFlip to move the selection around. Naturally, neither a standard NSTableView nor a custom NSResponder implement default behavior for (most of) the methods I need to support arrow key movement, tab movement, and the usual shortcuts, like Cmd-Left to jump to the first cell in the current row. Or Alt + arrow keys to insert a row or column next to the selection. So I implemented this in a custom NSResponder subclass.