| 4400
|
|
python: make all _get_ref/_put_ref proper static methods
The pyright static type checker doesn't like for these methods in
_SharedObject:
@staticmethod
def _get_ref(ptr):
raise NotImplementedError
@staticmethod
def _put_ref(ptr):
raise NotImplementedError
... to be overriden by assignment like this:
_get_ref = staticmethod(native_bt.field_class_get_ref)
_put_ref = staticmethod(native_bt.field_class_put_ref)
The warnings it gives are:
/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/field_class.py
/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/field_class.py:48:16 - error: Expression of type "staticmethod[(field_class: Unknown), Unknown]" cannot be assigned to declared type "(ptr: Unknown) -> Unknown"
Type "staticmethod[(field_class: Unknown), Unknown]" cannot be assigned to type "(ptr: Unknown) -> Unknown"
Parameter name mismatch: "ptr" versus "field_class" (reportGeneralTypeIssues)
/home/smarchi/src/babeltrace/src/bindings/python/bt2/bt2/field_class.py:49:16 - error: Expression of type "staticmethod[(field_class: Unknown), Unknown]" cannot be assigned to declared type "(ptr: Unknown) -> Unknown"
Type "staticmethod[(field_class: Unknown), Unknown]" cannot be assigned to type "(ptr: Unknown) -> Unknown"
Parameter name mismatch: "ptr" versus "field_class" (reportGeneralTypeIssues)
So, it's just the parameter name that it doesn't like. The obvious
solution would be to rename the `ptr` parameters of
_SharedObject._{get,put}_ref to `field_class`, in _SharedObject, to
match the names in native_bt.py. However, I don't want us to be tied to
the names in native_bt.py (which originally come from the C header
files), as in Python we often want to use `ptr` in the name to
differentiate the SWIG wrapper around the pointer and the higher-level.
Another solution might be to use SWIG code to rename function parameters
in the SWIG-generated code, but I'm not so well-versed in SWIG, I
couldn't find how to do that.
So, I propose to just use the standard syntax for methods instead, the
type checker seems to be happy with that.
Change-Id: Ife5ad007aea4fb315d3ff4f8da67c48f4bf3e96d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10240
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
|
Simon Marchi |
11 months ago
|
 |
|
| 4399
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4398
|
|
|
Philippe Proulx |
11 months ago
|
|
|
| 4397
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4396
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4395
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4394
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4393
|
|
tests: add framework to run code in comp cls / comp / msg iter context
Add a little framework to make it easier to write tests that need a
bt_self_component_class, bt_self_component or bt_self_message_iterator.
This is inspired from what we have already in
tests/lib/conds/utils.{hpp,cpp}, but decoupled from the
pre/post-condition assertion tests. A subsequent commit will change
this test to use the new framework.
The framework exposes the run_in function, which accepts three callbacks
that are executed at three different points in the graph's lifecycle,
providing access to all three contexts. Each callback may be nullptr.
For convenience, there are also three functions to run code in each
individual context:
- runInCompClsQuery
- runInCompClsInitFunc
- runInMsgIterClsInitFunc
If needed, some additional hook points can be added later, to access
other points of the graph's lifecycle.
The run_in function makes an end-to-end run:
- creates a graph
- creates a source component class
- makes a query on that component class
- adds a source component
- adds a dummy sink component, connects the ports of the two components
- runs the graph
Even for a test that only needs to run code in component class context,
for instance, we still run the whole enchilada. This is a bit
inefficient, but given that this is just for testing, we don't really
care, as it still runs quick.
Change-Id: Ie532b316dc330758b60fd5f6fe9499f0555f8a8a
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10060
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>
|
Simon Marchi |
11 months ago
|
|
|
| 4392
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4391
|
|
|
Francis Deslauriers |
11 months ago
|
|
|
| 4390
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4389
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4388
|
|
|
Simon Marchi |
11 months ago
|
|
|
| 4387
|
|
|
Simon Marchi |
1 year ago
|
|
|
| 4386
|
|
|
Simon Marchi |
1 year ago
|
|
|
| 4385
|
|
|
Simon Marchi |
1 year ago
|
|
|
| 4384
|
|
|
Simon Marchi |
1 year ago
|
|
|
| 4383
|
|
|
Simon Marchi |
1 year ago
|
|
|
| 4382
|
|
lib: remove duplicated assertion in bt_self_component_source_add_output_port
The use of BT_ASSERT_PRE_OUTPUT_PORT_NAME_UNIQUE in
bt_self_component_source_add_output_port is not necessary, as
bt_component_add_output_port checks the same thing:
BT_ASSERT_PRE_FROM_FUNC(api_func, "output-port-name-is-unique",
bt_component_port_name_is_unique(component->output_ports, name),
"Output port name is not unique: name=\"%s\", %![comp-]c",
name, component);
Remove this use of BT_ASSERT_PRE_OUTPUT_PORT_NAME_UNIQUE, and then
remove BT_ASSERT_PRE_OUTPUT_PORT_NAME_UNIQUE itself. Then, make
bt_component_port_name_is_unique static to component.c, since it's only
used in that file now.
Change-Id: Ia341be570596d798179d1937b40726f829cbebfe
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10035
Tested-by: jenkins <jenkins@lttng.org>
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
|
Simon Marchi |
1 year ago
|
|
|
| 4381
|
|
|
Simon Marchi |
1 year ago
|
|
|
collapse all