C++ & Python API: add helpers for constructing an entity path

[emilk]

What

Added rr.new_entity_path, which constructs an entity path from a list of strings.
rr.log also accepts such a list of unescaped strings directly.

In C++, rerun::new_entity_path has been added, e.g. rerun::new_entity_path({"world", "unescaped string!"}).

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[abey79]

Maybe there is an opportunity to go for the more modern and familiar pathlib.Path approach:

rr.EntityPath("world") / "robot"
rr.EntityPath.root() / "world" / file_name / "some string"

Following this thread, and like pathlib.Path, log operations could be added as helper method:

entity = rr.EntityPath("world") / "camera"
entity.log(rr.Points3D(...))

Overall, this would give a very Pythonic look:

world = rr.EntityPath("world")
world.log(rr.Transform(....)

for stuff in my_world:
    entity = world / stuff.name()
    entity.log(rr.Points3D(...))

[emilk]

I like it, but create an issue for it - it is a much bigger task

[abey79]

I like it, but create an issue for it - it is a much bigger task

#4596

[Wumpf]

roundtrip test for C++ needs activating

Otherwise noted a few things I might have done differently on the interfaces, but not a strong preference so up to you 👍

[Wumpf]

suggestion:
instead of doing the alloc/free dance a slightly safer alternative would be to use the "buffer in, count inout" pattern:

int rr_escape_entity_path_part(rr_string part, char* buffer, int buffer_size);

In this fairly common C pattern the desired count is returned but the buffer isn't fully written. Meaning one can either pass a null for buffer to just figure out the size one needs to allocate, or speculatively put in a buffer and check whether a second call is needed.

The advantage is that in many cases only one call is needed and that allocation stays with the caller.
The disadvantage is that when passing null buffer or too small buffer initially, this bottoms out in more work being done.

[Wumpf]

don't quite understand why new_entity_path is not fully implemented in the c interface

[emilk]

I went with this implementation because it was much faster to implement. But it's also why I made it private.

[emilk]

don't quite understand why new_entity_path is not fully implemented in the c interface

I don't understand the question. new_entity_path returns a std::string, so cannot be defined in C.

[Wumpf]

you could pass in several rr_string and write to a single char* buffer

[Wumpf]

I believe this should take a rerun collection. That way you can also call it with a single string view without overloading

Then again maybe that's a disadvantage because it muddles with the semantics of "list of path parts" 🤔

[emilk]

There is plenty of room for improvement. I'd love to be able to call it with a mix of strings and integers to, and have the implementation call to_string on each non-string, but I feel this is good enough for now.