Day 10 : 17 June 2022 : Logging Part 1

My 100 Daze of Code

https://github.com/davidjwalling/100-days-of-code

#10 : Logging Part 1

So far, our Log class has only supported storing operating system and application error codes. Our Driver class has exposed an AppErr method for returning the latest application error code. Error codes are set in a few places within the code.

Today's update will implement code to output a running log with messages containing a date and time, a message identifying code and message text. Log output is governed by a "log level" which is set at the start of the program but can be adjusted while the program is running.

For today, log messages will be written to a file. In later updates, we'll plan to add the ability to route log messages to application-layer handler or to write to the "syslog" facility on operating systems that support it.


Updates to IDriver

The IDriver class now provides a default constructor and destructor and Start and Stop methods. This will allow the Sockets I/O thread to be stopped and started at will. Note that the destructor will also call Stop in case we can't (or just don't) capture a terminate event in our app.


Log Codes and Messages

We'll make pretty liberal use of namespaces to organize our log message text and enums to automatically assign incrementing identifiers for them. Messages are defined in several classes, the driver, socket, etc. Here's an example of the driver message definition.


Log Macros

We've written Log::Write to handle the details of writing a log message. Now, we'd like to define some macros that will take a variable number of arguments and log only if the current log level is met.



Calling the Log Macros

We invoke some of the logging macros in our driver's Service and Finalize routines to output messages. By default, these are written to both the console and to file. The file name can be configured by setting a prefix, for now. The log file will roll over to a new file at midnight. 



Running on Linux, macOS and Windows

The main driver is updated now to call the default IDriver constructor, the IDriver::Start method and let the default destructor get called upon exit.

C++ on Windows trivia: If you include <iostream>, then "log" cannot be used as a namespace. So, we've wrapped our classes in the "ava" namespace to avoid name collisions like this.



Running on iOS with SwiftUI

We've updated the Objective C wrapper to correlate to changes in our IDriver class.

Our ContentView is updated to call the default driver (through init) and the Start method.


When debugging on iOS using Xcode on macOS, the log messages are seen in the Output window in Xcode.




 

Comments

Post a Comment

Popular posts from this blog

Day 12 : 19 June 2022 : Adding Windows Service Logic

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #12 : Adding Windows Service Logic Today, we'll add some Win32 API logic in Ava to install, uninstall and run as a service on Windows. We'll add logic in Driver::Service that check if the program was started with the "service" argument as the first program argument. If so, the Service Control Manager will be invoked to start the program as a service. We'll also check for "install" and "uninstall" program arguments and handle these with logic that installs and uninstalls the program, respectively. In a later post, we'll do the equivalent on Linux and macOS and show how to enable Ava to run as a daemon configured in sysctl. Nowadays there are shortcut methods to install and run an executable as a service on Windows. But I prefer to illustrate the APIs that make this work. Some Code Refactoring Up to now we've been using a pointer-to-implementation (pimpl) method for exp...
Read more

Day 5 : 12 June 2022 : CMake on Windows

Image
 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code Day 5 : 12 June 2022 : CMake on Windows So far, we've seen using CMake on Linux and MacOS. Also, we've looked at native compilation on Windows using Visual Studio (VS). Today, we'll look at using CMake on Windows. I decided to devote an entire day (hour) to this because there are several ways to invoke CMake on Windows, using different "Generators". A generator will write the inputs to the native build tools. But Wait, There's More ... Before heading to CMake, I wanted to first point out that VS' native tools can build just fine without using CMake, of course. To build using "msbuild," open an x64 Native Tools Command Prompt for Visual Studio - this is provided when VS is installed. Invoke msbuild and pass the solution name and the desired platform and configuration. msbuild ava.sln /p:Platform=x64 /p:Configuration=Debug Repeat for Debug and Release configurations for Win32 an...
Read more

Day 11: 18 June 2022 : Handling Program Arguments

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #11 : Handling Program Arguments Up to now we've been carrying around Ava's program argument count (argc) and value array (argv) into a Configure method. Now it's time to start doing something with those values. We'll define four program settings that can be set by passing program arguments: the logging level, path, prefix and suffix, and show examples of using them. Logging Parameter Storage The singleton theLog is instantiated inside the Ava library (libava). Default values for several logging parameters are set by the Log::Init method, which is called both by the Log class constructor and the destructor, by way of the Reset method, so that runtime values are not left in deallocated storage on operating systems that do not automatically clear memory upon deallocation. Logging Parameter Symbols We use namespaces and enums to define symbolic names for the logging parameters so that we have a single lo...
Read more