-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add send_recording
python api
#9148
base: main
Are you sure you want to change the base?
Conversation
send_recording
python api
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Independent on whether we want to solve this differently in the future, the APIs are very valuable to have I believe.
There's some todos left though for documenting this out etc.
Also, I don't think we should close the linked issue until we implement this in all SDKs (right now the PR auto closes #2044)
rerun_py/rerun_sdk/rerun/sinks.py
Outdated
@@ -472,6 +473,31 @@ def send_blueprint( | |||
) | |||
|
|||
|
|||
def send_recording(recording: Recording, stream: RecordingStream | None = None) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to be mentioned in gen_common_index.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we need a snippet using this.
Ideally we'd add it to all languages if only to have the snippet comparision test do something - I figure at least for Rust we could whip up something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added snippets for both rust/py 👍
rerun_py/rerun_sdk/rerun/sinks.py
Outdated
@@ -472,6 +473,31 @@ def send_blueprint( | |||
) | |||
|
|||
|
|||
def send_recording(recording: Recording, stream: RecordingStream | None = None) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this Python function at all? Can this logic be done in the Rust implementation instead? @jleibs has recently implemented a bunch of APIs for the Python SDK that don't have a single line of Python in them (AFAIK?), and I would very much like to keep that trend...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into it, but it doesn’t seem super straightforward in this case. There are a few things that make it a bit tricky, e.g. RecordingStream
wrapping PyRecordingStream
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. This can only be done correctly once everything else is done correctly. By "correctly", I mean according to this issue:
d4e6138
to
b727ab8
Compare
b727ab8
to
ffa7c43
Compare
@@ -488,6 +490,31 @@ def send_blueprint( | |||
) | |||
|
|||
|
|||
def send_recording(embedded_recording: Recording, recording: RecordingStream | None = None) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This absolutely needs to also be a RecordingStream
method.
Also, I don't know if this has been discussed, but our naming is all over the place, as this signature makes it explicit.
As they say, in for a penny, in for a pound. My actionable (if drastic) suggestion is either:
- either rename all
recording: RecordingStream
arguments of the stateful API tostream: RecordingStream
, - or preferably remove those arguments altogether! (if you want to act on an existing recording stream, just use one of its method)
I'm strongly advocating for the latter option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is relevant: #9187
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm late to the party on this one, but we should really think about the flow between the Recording
and a RecordingStream
object a bit more.
For example: the MemoryRecording
would ideally go away and just be a Recording
. Would be so nice to be able to log to the in-memory recording and then query it without needing to re-load it from an rrd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.rrd isn't checked in as a LFS file, should be though
otherwise (and remaining comment) looks all good to me now. I'd be in favor of landing this prior to additional Python refactors, but I'll let you and @abey79 figure that out ;-)
if let Some(info) = store.info().cloned() { | ||
let new_recording = rerun::RecordingStreamBuilder::new(info.application_id.clone()) | ||
.recording_id(store_id.to_string()) | ||
.spawn()?; | ||
|
||
new_recording.record_msg(LogMsg::SetStoreInfo(SetStoreInfo { | ||
row_id: Tuid::new(), | ||
info, | ||
})); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[not actionable] oof this is pretty wild, going way more into Rerun's guts as a would like. Ah well, why not. At least this gives us a great reference point testing the python layer! 👍
@@ -80,6 +80,9 @@ features = [ | |||
"cpp", | |||
"rust", | |||
] | |||
"concepts/send_recording" = [ # No output |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"concepts/send_recording" = [ # No output | |
"concepts/send_recording" = [ # Not implemented for C++ |
ideally with issue link, but can let it slide
|
||
path_to_rrd = sys.argv[1] | ||
|
||
recording = rr.dataframe.load_recording(path_to_rrd) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for not mentioning earlier, but I think it's super important that we point out that if you just want to send an rrd file in, one should use log_file
. This however is just a demonstration of glueing rr.dataframe
in.
Already can see people copying this for loading RRDs 😬
@@ -89,6 +89,7 @@ class Section: | |||
"disconnect", | |||
"save", | |||
"send_blueprint", | |||
"send_recording", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this isn't really an "initialize" function, right? All the others here are about setup, whereas send_recording is technically more like a logging function 🤔
Related
Resolves #2044 somewhat
What
Adds api to send a recording loaded from RRD to a new recording stream, cloning the data in the process