fieldrndservices/logger

A Log4j-like library for LabVIEW

logger's Issues

Double quotes in the message text need to be escaped

If the message contains a double quote, it should be represented with a pair of double quotes as per the CSV standard.

'this is a "message" with quotes' ->'this is a ""message"" with quotes'

otherwise it is difficult to parse the CSV file.

Feature Request: Automatically increase call chain index by 1 when Logger is running from a Packed Project Library

We have made hard coded changes to our local code to increase the call chain index by +1 to avoid getting the packed project library included in the call chain. I'm not entirely sure how to implement this in a clean way, so before I invested a bunch of time I thought I could submit here to see if there was any interest.

Bump development version to LabVIEW 2020

The current development version is LabVIEW 2018. Upgrading to LabVIEW 2020 should be investigated. This is different than the minimum supported version (LabVIEW 2010). This is would be the version of LabVIEW needed to modify and contribute to the codebase.

Add configurable delimiter

Currently, the delimiter is hard-coded as a comma to create Comma-Separated Values (CSV) log files, but it would be nice to be able to configure the delimiter so that Tab-Separated Values (TSV) log files could be created.

Re-architecting Logger into Actor Framework (Feature Request)

I really love Logger right now, so this suggestion is purely hypothetical. I have been using Logger as part of some Actor Framework based applications. We started with a PPL of the logger code so that we could treat Logger like a standalone library that can be swapped out or shared as needed across multiple application development efforts easily.

I was wondering if anyone else has ever suggested converting the Logger architecture to the Actor Framework so that the FGV would map over to class data and the listeners would be spawned actors instead of just passing a listener queue. This is not a fully baked suggestion, just thinking out loud.

Index to Callchain-array 0 instead of 1 in some of the Action Vis

In some of the reporting action VIs (trace, debug, info, ...) and the catch error VI, the source of the message is set to the 0th element of the callchain, which is the VI from the logging library.

I assume this should have been the VI that is issuing the report, which would be the first element.

File Start throws error when used in EXE

Setting a control value via invoke node does not work when used as a sub-VI in the EXE as the frontpanel is usually removed.

Fix: replace static VI ref with strictly typed static VI ref and use "Start Asynchronous Call" Vi.

Inline Unchecked within Package

Following from #3 and @fuzzy-focus comment, the inline checkbox for the VI's execution properties are unchecked in the package (VIP).

I believe I found the source of the problem. Inlining is not supported in LabVIEW 2009. So, when the project is saved to LabVIEW 2009 for packaging, the inlining is dropped and the checkbox is unchecked for all versions of LabVIEW newer than 2009.

Inlining was introduced in LabVIEW 2010. Support for LabVIEW 2009 will be dropped and the minimum LabVIEW version will be 2010 for all future releases.

Prune.vi only checks for logfiles with *.csv extension

If a custom extension (e.g. *.log) is used, old logfiles will never be deleted as they are not checked for.

Maximum File Size parameter does not have units specified

Maximum File Size configuration parameter does not have units specified. I guess it is in bytes, but it would be great to mention it somewhere.

Calling shutdown without a completely configured instance of logger leads to errors

In order to ensure there is no stray logger instance active (ensure a known good starting state), I call StopFile and Shutdown before initializing and starting logger during the initialization phase of my application. However, when I do this with the current library I encounter what could be considered unhandled exceptions (or properly thrown errors 😂). This is easy to simulate by calling StopFile & shutdown without an active, configured instance of logger present.

Proposed Changes:

1. File.lvlib->Manager.vi : "Stop" case modified to check if the root log folder path refnum is "Not a Refnum" before trying to close it.
2. Unregister.vi : "False" case modified to include Clear Errors.vi with error code 1 cleared when the Listener ID is not found. It doesn't seem like there is a reason to pass the error since a listener ID that isn't in the Listeners queue collection won't need to be unregistered - it already is by default
3. Release.vi : This vi tries to release all listener queues, but if there are none (i.e. logger uninitialized) then Release Queue will throw error code 1. Adding the Clear Errors.vi with error code 1 cleared ensures this won't error out if the queues don't yet exist.
4. Shutdown.vi : After the default listener queue is flushed, check if the array of elements is empty. If empty, don't try to write the contents to the log file.

Missing Flush File can lead to data loss

We're investigating the Logger framework for use on a real-time system. It seems to work fine so far, except one issue. When the controller shuts down unexpectedly (power loss in the middle of operation) the logfile is deleted after the restart. It might be because the file is never actually written to disk, but is only in memory.
I looked at the code, and I added a Flush File in the False case in File.lvlib:Write.vi. This seems to resolve the issue, the logfile is still there after an unexpected shutdown.
I'm aware this might have consequences on the performance, since this forces the file write to disk to be synchronous instead of leaving the decision when to actually write to file to the OS. So probably the best thing would be to make this configurable.

My workaround:

Other minor points:

• File.lvlib:Manager.vi and some other VIs have debugging enabled. This is not ideal for performance reasons.
• Did you consider setting the "Separate compiled code from source file" checkbox?