[HN Gopher] Rerun OSS beta is released
___________________________________________________________________
Rerun OSS beta is released
Author : fdb
Score : 186 points
Date : 2023-02-15 17:10 UTC (5 hours ago)
(HTM) web link (www.rerun.io)
(TXT) w3m dump (www.rerun.io)
| NayamAmarshe wrote:
| Congratulations!
| nikonp wrote:
| Thanks! It will be fun to hear what people think after giving
| it a try
| cloverTiger88 wrote:
| excited to give it a try!
| emilern wrote:
| Hi there - CTO of Rerun here!
|
| Rerun is still in beta, but we think it's already good enough to
| be useful. It is built on wgpu, Apache Arrow, my own egui.rs
| library, and it also runs as Wasm in the browser.
|
| I'm happy to answer any questions you may have!
|
| PS: Thanks for the shoutout fdb!
| melony wrote:
| I came across rerun from egui too. Egui is a very good
| marketing funnel.
| mwcampbell wrote:
| A bit tangential, but since you're using wgpu in your own
| product now, do you have any plans to switch to using wgpu by
| default in eframe, and possibly even eliminate glow? I'm just
| curious; this probably doesn't have any effect on anything I'm
| working on. Anyway, eliminating the multiple code paths in
| eframe would be nice.
| emilern wrote:
| Switching to wgpu as the default is a definite possibility,
| but something should be said for the simplicity of the glow
| backend. wgpu is a big beast, which takes more time to
| compile, and for a lot of eframe users it is simply over-
| kill.
|
| ...but then again, if you want simplicity and fast compiles,
| I can recommend the egui-miniquad backend. It's not as fully-
| featured as eframe, but with some love it could definitely
| get there.
| mikaeln wrote:
| Congrats. I'm also a COSS founder and think this is a very smart
| step for a product like rerun. Feel free to ping me if you want
| to chat open-source more.
| philsnow wrote:
| I got confused by the usage of the term "log" (and the word gets
| used so much in many pages that I hit semantic satiation).
|
| > When you log data to the Rerun SDK, Rerun handles everything
| needed to visualize it. It handles live streams from multiple
| processes across the network, as well as simple playback from
| recordings. That means taking care of serialization, transport,
| synchronizing streams, out-of-order data, and automatically
| constructing visualizations with sane defaults.
|
| so is "record" / "recording" the right concept? When I think of
| logging I think of _exactly_ lines in a text file (or maybe the
| "log" from a logging filesystem).
| nikonp wrote:
| One of the founders here. I totally see where you're coming
| from. If you come from a world where log equals text, then
| using log for anything else seems strange.
|
| In robotics and autonomy, "log" is commonly used for e.g.
| sensor data or planning decisions as well. But even outside
| those fields it isn't uncommon to talk about logging metrics
| for instance.
|
| Still, no metaphor is perfect and we have spent a lot of time
| discussing what word to use. "Record" gives me the sense that
| the main purpose is to save the data for later. Rerun is also
| about the live use case. There words like "stream" or "send"
| could work perhaps.
|
| In the end we decided on "log" because it is short, is already
| used in a similar way in some of the areas we hope Rerun will
| be used, and because data can either be stored on disk and/or
| be streamed/uploaded somewhere (like with regular text logs).
| jeremyleibs wrote:
| Hello -- Rerun developer here. You are correct on both counts.
| The terminology used in some places is a bit inconsistent, and
| "recording" is very much the right concept to apply to the data
| that Rerun captures.
|
| However, one of the reasons we tend to think of our APIs as
| being "logging" like is that much like other console-logging
| libraries, the primary purpose is to get data out of your
| program and into a user-observable form. Also similar to other
| logging libraries, the APIs are intended to have no side
| affects on your program so they can actually be disabled with a
| function call or by setting an environment variable in
| situations where you don't need the additional context for
| debugging or inspection.
|
| I appreciate the feedback though and will make sure to take a
| pass on the docs to see if I can make the relationship and
| intent a bit more clear.
| [deleted]
| pipework wrote:
| The rr command is already somewhat well-known as a debugger from
| the rr-project[0]. Rerun is definitely inspiring, and good tools
| do that. Brett Victor is a great inspiration, I'm glad I saw that
| his work inspired rerun, that's cool.
|
| [0]: https://rr-project.org/
| 2h wrote:
| here are some pictures, if like me you have no idea what this is:
|
| https://www.rerun.io/docs/getting-started/examples
| sigg3 wrote:
| IMO relevant blurb:
|
| > Rerun is an SDK for logging data like images, tensors and point
| clouds, paired with an app that builds visualizations around that
| data. We built Rerun for computer vision and robotics developers.
| It makes it easy to debug, explore and understand internal state
| and data with minimal code. The point is to make it much easier
| to build computer vision and robotics solutions for the real
| world.
| [deleted]
___________________________________________________________________
(page generated 2023-02-15 23:01 UTC)