Project

General

Profile

Actions

Feature #1049

closed

Some nice-to-have features of the babeltrace Python 3 bindings

Added by Daniel U. Thibault almost 8 years ago. Updated about 4 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07/18/2016
Due date:
% Done:

0%

Estimated time:

Description

An iterator for each of the sets of common constants (and the two missing constant-to-name functions):

babeltrace.CTFStringEncodings (in numerical order: NONE, UTF8, ASCII, UNKNOWN)
babeltrace.string_encoding_name(ctfse)

babeltrace.ByteOrders (in numerical order: BYTE_ORDER_NATIVE, BYTE_ORDER_LITTLE_ENDIAN, BYTE_ORDER_BIG_ENDIAN, BYTE_ORDER_NETWORK, BYTE_ORDER_UNKNOWN)
babeltrace.byte_order_name(ctfbo)

babeltrace.CTFTypeIds (in numerical order: UNKNOWN, INTEGER, FLOAT, ENUM, STRING, STRUCT, UNTAGGED_VARIANT, VARIANT, ARRAY, SEQUENCE)

babeltrace.CTFScopes (in EventDeclaration.fields order: EVENT_FIELDS, EVENT_CONTEXT, STREAM_EVENT_CONTEXT, STREAM_EVENT_HEADER, STREAM_PACKET_CONTEXT, TRACE_PACKET_HEADER)

An iterator over the trace handles:

babeltrace.TraceCollection.traces

A TraceHandle way back to the owning TraceCollection(s). If each TraceHandle is unique to a TraceCollection, then a simple read-only field is all that is required. If each TraceHandle can belong to several TraceCollections@s, then a @collections iterator would do it.

Some way of telling whether a TraceHandle is valid would be nice, too. I presume the TraceHandle@s returned by @TraceCollection.add_trace or TraceCollection.add_traces_recursive are no longer valid once the trace has been removed from its owning TraceCollection(s) by TraceCollection.remove_trace.

Actions

Also available in: Atom PDF