https://github.com/github/renaming

setup.cfg specifies python_requires = >=3.6, but attempting to use traceloggingdynamic with Python 3.8 on Windows raises TypeError:

PS D:\dev\project> poetry run python
Python 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import traceloggingdynamic
>>> provider = traceloggingdynamic.Provider(b"MyProvider")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\dev\project\.venv\lib\site-packages\traceloggingdynamic.py", line 1265, in __init__
    self.id = id if id != None else providerid_from_name_bytes_utf8(name_utf8)
  File "D:\dev\project\.venv\lib\site-packages\traceloggingdynamic.py", line 113, in providerid_from_name_bytes_utf8
    return providerid_from_name(str(providername_utf8, encoding='utf-8'))
  File "D:\dev\project\.venv\lib\site-packages\traceloggingdynamic.py", line 93, in providerid_from_name
    sha1 = hashlib.sha1(usedforsecurity = False)
TypeError: 'usedforsecurity' is an invalid keyword argument for openssl_sha1()

The hashlib docs say that usedforsecurity was added in Python 3.9.

Minor hygiene issue: https://github.com/microsoft/tracelogging/blob/f7ba38f9d3f77c145754bd9639f87d455b6c0b9f/LTTng/README.md

What's the ask: remove the general info from the LTTng README.md since these are already covered by the repo level readme doc.

I'd like to add support for std::[w]string[_view] and a related type winrt::hstring ... I put together https://github.com/jonwis/jonwis.github.io/tree/in-progress/code/TlgAutoTest as a header on top of the existing TraceLoggingProvider.h for C++.

Is http://github.com/microsoft/wil a better place to put this kind of helper?

traceloggingdynamic.py has type hints, but type-checking client code with mypy results in the following errors:

my_module.py:4: error: Skipping analyzing "traceloggingdynamic": module is installed, but missing library stubs or py.typed marker  [import]
my_module.py:4: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Found 1 error in 1 file (checked 54 source files)

https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-library-stubs-or-py-typed-marker says

Mypy will not try inferring the types of any 3rd party libraries you have installed unless they either have declared themselves to be PEP 561 compliant stub package (e.g. with a py.typed file) or have registered themselves on typeshed, the repository of types for the standard library and some 3rd party libraries.

https://peps.python.org/pep-0561/#packaging-type-information says

Package maintainers who wish to support type checking of their code MUST add a marker file named py.typed to their package supporting typing. This marker applies recursively: if a top-level package includes it, all its sub-packages MUST support type checking as well.

I think the solution is to rename traceloggingdynamic.py to traceloggingdynamic/__init__.py and create an empty file traceloggingdynamic/py.typed.

Workaround: for mypy, specify --ignore-missing-imports

Current documentation for LTTng recommends using this project as a subdirectory in the consuming project. Would it be possible to consume LTTng through a vcpkg (https://github.com/microsoft/vcpkg) port?

I'm noticing that GPUView has some trouble displaying events logged using the TraceLogging API.

It seems that the first event name to be logged using the TraceLoggingWrite is the only one that will show up in GPUView.

i.e.

void main()
{
...
		TraceLoggingWrite(g_hMyProvider, "EventA");    // <- This event will appear in GPUView
		TraceLoggingWrite(g_hMyProvider, "EventB");    // <- This event will not appear in GPUView
                TraceLoggingWrite(g_hMyProvider, "EventA");    // <- This event will appear in GPUView
...
}

I've confirmed that the traces are good as TraceView is able to display all of the events as expected.

Is there anything I can do to make TraceLogging play nicely with GPUView? Or would it make more sense for me to switch to using a manifest based ETW solution?

I'm compiling with latest VC, using C++20, and I'm seeing errors in TraceLoggingDynamic.h due to some of the SAL annotations, e.g.:

void AddBytes(
    _In_bytecount_(cb) void const* p,
    unsigned cb)

I think this should be _In_reads_bytes_(cb) based on SAL 2 syntax.

OpenTelemetry .NET Geneva Exporter is onboarding to serialize data using ETW/ TraceLoggingDynamic. However, we have a limitation on the maximum number of characters allowed for any string field. Any string logged cannot be longer than 16383 (2^14 - 1) characters. When we encounter a string that exceeds the maximum length allowed, we truncate it and take the first 16380 characters and append three dots ... to the end of it to denote that this string was truncated.

The current set of APIs provided in TraceLoggingDynamic.cs take in an input string and write that as a field. We would like to log a truncated string in most performance efficient way possible. We want to avoid the allocation for the resultant string. A few possible solutions to this problem:

• TraceLoggingDynamic provides an API that takes in a Span<char> or a char[] and writes it as a new field. This would entail the GenevaExporter to maintain a dedicated character array where we store the truncated string and pass that to the TraceLoggingDynamic API

• TraceLoggingDynamic provides an API that takes in a string, startIndex, and length and writes the selected portion of the input string as a field.

Please leave your suggestions about these two approaches or anu other ways of achieving this.

#33 (comment)

Hi Team,
How does this Trace Logging helper for ETW compare(Performance and overhead) with manifest-based provider?

Thanks

The 2.10 version of lttng library is no longer experimental. In fact as of today 2.11 is available and installed by default from mainstream places like ubuntu package repos. For example on a vanilla Ubuntu device I see the following:

(note I am not running add-repository first)

$ sudo apt install liblttng-ust-dev

$ sudo apt show liblttng-ust-dev
Package: liblttng-ust-dev
Version: 2.11.0-1

Accordingly my proposal is you should drop the add-repository step from your instructions, for three reasons:

• Simplicity
• Keep up with bug fixes in lttng
• the unnecessary add-repository step results in a system-wide degradation (depending on your point of view), in that it results in security warning every time your run apt update, etc.