Tamás Nepusz

Okay, but then why is this not a problem for GraphML? The same construct is being used there (i.e. loop over all vertices/edges, then within each vertex/edge loop over all...

It's only the C attribute handler, which, in its current state, is yet another example of a temporary solution that turned out to be permanent :-D It was never meant...

Thanks! I'll merge now and then add a few tweaks in a subsequent commit.

We are investigating this right now and to be honest I don't understand yet why this line is needed; `update_rssi()` takes the existing RSSI list from the status object itself...

When a new `UAVStatusInfo` object is created, it is assigned an empty list in its `rssi` property, [here](https://github.com/skybrush-io/skybrush-server/blob/main/src/flockwave/server/model/uav.py#L105). In `update_rssi`, a reference to that list is taken [here](https://github.com/skybrush-io/skybrush-server/blob/main/src/flockwave/server/model/uav.py#L311), and then...

The latest version (2.25.1) now has support for dual RSSI values (primary and secondary channels) and it seems to work fine according to reports received from others so I'm closing...

Apparently this should be fixed in the most recent version of `electron-builder`. See https://github.com/electron-userland/electron-builder/issues/6678 and https://github.com/electron-userland/electron-builder/issues/8351 . `[email protected]` or later should be okay. Needs testing.

> I think you added it when handling the PR for igraph_spanner()? Do you remember your reasoning for it? Yes. Originally it was inlined into the `igraph_spanner()` function and it...

> if vectors in an adjacency list are supposed to be sorted, then it would currently be the job of `igraph_adjlist_init_from_inclist()` to ensure this property, so yes, that should be...

I believe that both use-cases have some merit. Most constructors of `igraph_adjlist_t` return vertex IDs in ascending order, but this is not guaranteed or explicitly documented anywhere. Some igraph algorithms...