-
-
Notifications
You must be signed in to change notification settings - Fork 137
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
console: bold field names #35
Conversation
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
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.
overall, this looks pretty good, although I had some suggestions you may want to address.
a number of these are things we could also change in follow-up PRs if you prefer --- feel free to merge this now if you'd rather address some of those suggestions in a follow-up, or let me know once you've updated this branch?
console-api/src/common.rs
Outdated
impl fmt::Display for field::Value { | ||
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | ||
match self { | ||
field::Value::BoolVal(v) => fmt::Display::fmt(v, f)?, | ||
field::Value::StrVal(v) => fmt::Display::fmt(v, f)?, | ||
field::Value::U64Val(v) => fmt::Display::fmt(v, f)?, | ||
field::Value::DebugVal(v) => fmt::Display::fmt(v, f)?, | ||
field::Value::I64Val(v) => fmt::Display::fmt(v, f)?, | ||
} | ||
|
||
Ok(()) | ||
} | ||
} | ||
|
||
impl fmt::Display for Field { | ||
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | ||
let name_val = (self.name.as_ref(), self.value.as_ref()); | ||
if let (Some(field::Name::StrName(name)), Some(val)) = name_val { | ||
write!(f, "{}={}", name, val)?; | ||
} | ||
|
||
Ok(()) | ||
} | ||
} |
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 think it's probably worth keeping these in the console-api
crate, even if we're not currently using them in the console, but TIOLI.
console/src/tasks.rs
Outdated
if let Some(new_metada) = update.new_metadata { | ||
let metas: HashMap<_, Metadata> = new_metada |
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.
nit: i'd prefer either
if let Some(new_metada) = update.new_metadata { | |
let metas: HashMap<_, Metadata> = new_metada | |
if let Some(new_metadata) = update.new_metadata { | |
let metas: HashMap<_, Metadata> = new_metadata |
or
if let Some(new_metada) = update.new_metadata { | |
let metas: HashMap<_, Metadata> = new_metada | |
if let Some(new_meta) = update.new_metadata { | |
let metas: HashMap<_, Metadata> = new_meta |
as i feel like metadata is rarely, if ever, abbreviated as "metada"...
console/src/tasks.rs
Outdated
let metas: HashMap<_, Metadata> = new_metada | ||
.metadata | ||
.into_iter() | ||
.map(|meta| { | ||
let id = meta.id.expect("no id").id; | ||
let metadata = meta.metadata.expect("no metadata"); | ||
(id, metadata.into()) | ||
}) | ||
.collect(); | ||
self.metas.extend(metas); |
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.
nit: the extend
method takes a T: IntoIterator
, and all types implementing Iterator
also implement IntoIterator
. so, we don't need to call collect
here and could skip allocating an intermediate hashmap --- making the code slightly simpler and removing an unnecessary allocation.
let metas: HashMap<_, Metadata> = new_metada | |
.metadata | |
.into_iter() | |
.map(|meta| { | |
let id = meta.id.expect("no id").id; | |
let metadata = meta.metadata.expect("no metadata"); | |
(id, metadata.into()) | |
}) | |
.collect(); | |
self.metas.extend(metas); | |
let metas = new_metada | |
.metadata | |
.into_iter() | |
.map(|meta| { | |
let id = meta.id.expect("no id").id; | |
let metadata = meta.metadata.expect("no metadata"); | |
(id, metadata.into()) | |
}); | |
self.metas.extend(metas); |
metas | ||
.get(&meta_id.id) | ||
.and_then(|meta| meta.field_names.get(*idx as usize)) | ||
.cloned() |
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.
it might be worth representing the metadata's field names as Arc<str>
s, so that they are cheap to clone --- once the subscriber populates the metadata field names, we can expect most spans to have field names stored as indices rather than strings, so we could significantly reduce the number of strings the console allocates if we only stored a single copy of those strings in the metadata, and cloned an Arc
into the task's fields.
it would be fine to do this in a follow-up PR, though --- this is fine for now.
console/src/tasks.rs
Outdated
.iter() | ||
.fold(String::new(), |mut res, f| { | ||
write!(&mut res, "{} ", f).unwrap(); | ||
res | ||
.filter_map(|f| { | ||
let field_name = f.name.as_ref().expect("no name"); | ||
let name = match field_name { | ||
proto::field::Name::StrName(n) => Some(n.clone()), | ||
proto::field::Name::NameIdx(idx) => { | ||
let meta_id = f.metadata_id.as_ref().expect("no id"); | ||
metas | ||
.get(&meta_id.id) | ||
.and_then(|meta| meta.field_names.get(*idx as usize)) | ||
.cloned() | ||
} | ||
}; | ||
let value = f.value.as_ref().expect("no value").clone().into(); | ||
name.map(|name| Field { name, value }) |
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.
we never reuse the protobuf Task
's fields, so we shouldn't have to clone them here. if we moved the fields by value, we could write something like this instead:
let fields = task
.fields
.drain(..)
.filter_map(|f| {
let field_name = f.name.expect("no name");
let name = match field_name {
proto::field::Name::StrName(n) => Some(n),
proto::field::Name::NameIdx(idx) => {
let meta_id = f.metadata_id.as_ref().expect("no id");
metas
.get(&meta_id.id)
.and_then(|meta| meta.field_names.get(*idx as usize))
.cloned()
}
};
let value = f.value.expect("no value").into();
name.map(|name| Field { name, value })
})
.collect();
console/src/tasks.rs
Outdated
let fields = Spans::from(task.fields().iter().fold(Vec::default(), |mut acc, f| { | ||
acc.extend(vec![ | ||
Span::styled( | ||
f.name.clone(), | ||
Style::default().add_modifier(Modifier::BOLD), | ||
), | ||
Span::from("="), | ||
Span::from(format!("{} ", f.value)), | ||
]); | ||
acc | ||
})); |
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.
hmm, this change is actually a performance hit, because we are now formatting the fields again every time we update the view, rather than just once.
it might be worth having the Task
struct store the formatted representation as well as the structured representation (which we would use for things like sorting/filtering by fields). we could have some logic for determining when to re-format the fields if the task span records new fields (which currently won't happen, but we may add in the future).
again, we don't have to do that in this PR, but it might be nice to do in the future as an optimization?
console/src/view/task.rs
Outdated
let fields: String = task | ||
.fields() | ||
.iter() | ||
.fold(String::new(), |mut res, f| { | ||
write!(&mut res, "{}={} ", f.name, f.value).unwrap(); | ||
res | ||
}) | ||
.trim_end() | ||
.into(); |
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.
it would be nice to do the same formatting here as we do in the tasks list view? but again, we can add that in a follow-up if you prefer.
@@ -39,12 +41,19 @@ enum SortBy { | |||
pub(crate) struct Task { | |||
id: u64, | |||
id_hex: String, | |||
fields: String, | |||
fields: Vec<Field>, | |||
formatted_fields: Vec<Span<'static>>, |
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.
is that 'static
correct.. 😕
This PR delays the formatting of the fields and instead
stores them on the
Task
struct. This allows for nicer formattingoptions. Currently we just bold the field names in the task tables view.
fix #33
Signed-off-by: Zahari Dichev zaharidichev@gmail.com