Skip to content
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 a raw pretty printer for the metadata format #2326

Closed
catamorphism opened this issue May 2, 2012 · 10 comments
Closed

Add a raw pretty printer for the metadata format #2326

catamorphism opened this issue May 2, 2012 · 10 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@catamorphism
Copy link
Contributor

Maybe everybody else is really good at this, but I find it really frustrating to debug issues with inconsistencies (introduced by me) between the decoder and encoder. I spent several hours just now tracking down a problem that turned out to be because I was encoding a type with a tag around it, but the decoder was expecting the raw type string with no tag. If I'd had a way to dump out the EBML being encoded and decoded, this would have been easy to see. I asked someone (can't remember who) about this a while ago, and they said that pretty-printing EBML would be hard to do because there's no DTD. So, even if it would require effort, I'd really like a way to pretty-print EBML, since it seems to me like it would save debugging effort.

@nikomatsakis
Copy link
Contributor

it's not super hard. we have constants for the various tags and a global tag namespace. we could make a simpler "DTD" which is basically just a function from tag uint to an enum like this:

enum ebml_dtd { elts, int, uint, str, ..., blob }

then we should be able to walk through and interpret things appropriately (if it is elts, we treat it like EBML text, otherwise interpret it as specified or just dumb the raw bytes)

@graydon
Copy link
Contributor

graydon commented Aug 9, 2012

We should not be doing any of this stuff raw; we should be using auto_serialize and a serializer-backend.

@bblum
Copy link
Contributor

bblum commented Jun 21, 2013

not really sure which milestone applies for developer convenience tools; maybe well-covered?

@pnkfelix
Copy link
Member

not accepted for milestone; as ben points out, developer convenience is not part of milestones.

@msullivan
Copy link
Contributor

Related to #8652. Could be useful, but for the effort it is probably more useful to vastly overhaul metadata...

@reem
Copy link
Contributor

reem commented Sep 15, 2014

Triage: Could still be an issue. I'm not familiar with this part of the codebase and can't really find anything relevant.

@steveklabnik
Copy link
Member

Triage: no change. There have been some large changes to metadata in the last few months, but that doesn't really apply here, to my knowledge.

@lifthrasiir did you do anything related to this when you worked on reform?

@lifthrasiir
Copy link
Contributor

@steveklabnik I have used an ad-hoc decoder to analyze metadata bloat, but that's all. (Also, that decoder does not support the current metadata format, but it is not very hard to adapt.) Nevermind, it turned out that I have updated the script, so it will likely work with the current format.

@arielb1
Copy link
Contributor

arielb1 commented Sep 26, 2015

I also have a decoder at https://github.com/arielb1/rtypes

@brson
Copy link
Contributor

brson commented Mar 9, 2017

Nice to have, but I don't think we need a tracking issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests