-
Notifications
You must be signed in to change notification settings - Fork 564
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
Towards improving read and rendering of results #1396
Conversation
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.
Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased)
section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed
This comment was marked as off-topic.
This comment was marked as off-topic.
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.
im sorry we didn't provide more detail on how we were thinking about going about this. i think we should rely on --json > output.json
to save the result document. for new functionality, we'll have to find a way to identify that the input file is a result document, and then do the rendering. determining the file type might be done like: 1) check for json content, a few strings we expect to be present, and then trying to deserialize it, or 2) requiring the user to specify format=result or similar as a cli argument.
please dont hesitate to reach out with questions or suggestions - we're excited to work with you on this enhancement!
This comment was marked as off-topic.
This comment was marked as off-topic.
I'm also in favor of this so we don't need a new command line argument and instead reuse |
This comment was marked as off-topic.
This comment was marked as off-topic.
i've updated #991 with more explicit details on how we were thinking this might work. please use this as guidance or coordinate with us if you want to propose alternative logic. we're open to other ideas but also sensitive to the current architecture of capa and what's on the roadmap. |
This comment was marked as outdated.
This comment was marked as outdated.
@williballenthin @mr-tz Made the final changes :) |
CHANGELOG updated or no update needed, thanks! 😄
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.
see feedback inline and let me know what questions you have
also, please prepare a few unit tests that demonstrate how the new functionality proposed here works as intended. |
This reverts commit 530e28c.
@williballenthin @mr-tz I hope I have resolved all the above discussions. |
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 are really close! i have a few requests inline, but i dont anticipate any of these should be difficult to address. if they are, dont hesitate to reach out and i'd be hapy to lend a hand. overall, i feel that the quality of this PR is really good, nice job!
there's also some conflicts to deal with from master, and we'll want the linters to pass again (code style is broken right now but should be fixed soon. if this becomes a blocker we can find a way around it). |
@williballenthin I have addressed the suggestions in inline |
awesome, logic looks good! please:
|
This comment was marked as outdated.
This comment was marked as outdated.
“xfail” means “expected to fail” so in fact we want these entries. I don’t see any “fail” in that output so it looks great!
|
great, thanks for the arch fix, @ooprathamm! once the remaining tests pass (aside from codestyle) i'll merge, thank again! |
@williballenthin I have fixed the reason of failing elf arch extraction. |
🎉 |
closes #991
Checklist