 |
ALox
V. 2402 R. 0
|
The English term "log" is known. Now "logs" is the plural. As English pronunciation is always a little unspecific and volatile, you could write the word "logs" as "lox" easily without changing the pronunciation. Now, as we were looking for some artificial new word for the project, we loved to turn "logs" into "lox".
But then we wanted to add the "A". This tells you: This is class A logging! Got it? So, please pronounce it in two words, with a separately spoken "a" like in "a car" or "a cat".
Note: This explanation also proves that the name has nothing to do with this lovely guy called Alex, because his name pronounced in one word!
Well, if you are not familiar with it, checkout Bauhaus on Wikipedia (and yes, we are a German team). Bauhaus in Software for us means: Simplicity, platform independence, efficiency and speed. While we are embracing all modern concepts of software development (the same as we love modern art, romantic, surrealistic, pop art, punk and rock!) we consider Bauhaus the right approach for core libraries - what ALox definitely is.
While applications and tailored software might have other goals in respect to life cycle, budget, portability and such, we think the design of a core library which is embedded in many projects and used by different teams should follow certain rules. For example, we are avoiding memory allocations as much as possible. In fact, after ALox performed some few Log Statements, the next statements will probably allocate/dispose just ZERO new objects! (Ok, some unavoidable platform depended things, like a DateTime object in C# to receive the current system time, which makes the DateTime class in C# in turn a great sample for non-efficient, non-Bauhaus code style that should never have gone into a core library called System!).
As a consequence, you will sometimes see code pieces where you might think: "Hmmm, they missed to use this great language feature XYZ here". Well, send us a note, but the answer will probably be: "This is not available in that other platform and we want to keep similar simple code bases.", or "Well, this would look nice in code, but would increase execution time."
Mean people (e.g. that bright fellow from Berlin) might say: You just do Bauhaus, because you can't do Pop Art. Maybe they are right. At least we love Bauhaus and we love to do efficient libraries and that's why we do!
PS: If you can tell us a way how to get the current system time in C# without the allocation of a DateTime object (what DateTime.Now does), then please send us an Email!
Update: Too late, we solved it! A little tricky and some static code was needed, but it works well. (See cs::aworx::lib::time::Ticks.)
ALox is fast (see previous question on Bauhaus). Using a MemoryLogger, in C# we measured more than 200.000 log entries per second on a Notebook (equipped with an Intel(R) Core(TM) i7 CPU @2.8GHz) while running an application (and ALox) in debug mode! Hence, if doing as much as 100 log entries per second, the performance loss for your application would still be a maximum of 0.05%.
Of-course, logging into a console is slower. But the good news is: As the internal management of ALox is so fast, there will not be a measurable difference between "normal" debug log output using printf(), System.out.println(), Console.WriteLine, etc. versus ALox logging. And: as for debug logging, this gets automatically pruned in the release code. Hence, the release version of your software is free of any performance issue caused by debug logging. (For example, C# users read Mission accomplished: Perfect Auto Pruning with ALox! for more information.)
The goals of debug logging and release logging are quite different. Debug logging is about adding Log Statements to your code that enables you to see on the terminal console, your IDEs output window or in a log-file, what your software currently does or recently did, what errors and warnings it produces, how long certain methods take to execute and whatever you want your software to tell you while testing it. Debug Log Statements should ultimately be pruned (see next answer) from release binaries.
Release logging is about generating a log file, a log database, an online-report to a server or whatever you choose during execution of your deployed software. Often, release logging is used for dealing with problems that arise when your software is used by the target audience. It is also useful to collect statistical data on the use of a software, identify problems that end-users might face, and so forth. Sometimes, release logging is a subset of the debug log, sometimes it is something completely different.
Technically however, both logging use cases require very similar software. Therefore, ALox aims to solve both in one library. Basic support for release logging is here today already. The introduction of new features and concepts in the area of release logging might also support debug logging aspects of ALox and vice versa. Therefore the natural path of evolution for the ALox library is "debug logging features first, release logging features next".
What we mean with the term "pruning" is the automatic removal of the (debug) logging code from your release binaries when they are ready for deployment. The goals that motivate for automatic pruning are:
Automatic pruning assures furthermore, that the above stays true for all debug logging statements while all release logging statements remain in the code. Such remaining release logging might be deactivated initially and activated in case of runtime errors, external triggers, or other special events.
For details on how pruning is implemented in the different flavors of ALox, refer to ALox C++ Macros, Pruning ALox for C# and Pruning ALox for Java.
Of-course the log content itself is unicode and hence supports your locale within your application. But the following is true: All configurable output of meta information is done in US/English locale. There is no config option to change this. The reason is, that log output is really something that is not for a different audience than the software developers and here, US/English rules (just look at the keywords of your programming language). And we think that a maximum of compatibility (e.g. with other tools or within international teams) is guaranteed this way.
If you absolutely want localized meta information, like logging the name of months in Finnish, you can extend ALox for that. Here is how you do that!
We would not say that ALox is "introducing" an own set of utility classes. ALox only builds upon such a set called ALib. They are located and documented in namespace [com::|cs::]aworx::lib (C++, C#, Java). We know that there are other, better and much more complete sets in the world. Our motivation is twofold: we design these classes that their interface is almost identical across programming languages. This helps us porting ALox to other languages and platforms. On the other hand, of-course, our classes are more internal and therefore can quite unabashedly follow the Bauhaus design principles. Again, we neither want to promote Bauhaus, nor the utility classes. It is just our code style when it comes to core stuff like logging libraries.
1.8.16