-
Notifications
You must be signed in to change notification settings - Fork 39
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
unify memory printing functions #311
base: develop
Are you sure you want to change the base?
unify memory printing functions #311
Conversation
This is far easier to reason about. e.g. "what percentage of an 8GiB loom is full when |mass shows 4GB total usage?" -- well, it's less than 50%. You'll have to do the base10->base2 conversion yourself.
c3_z | ||
_c3_printcap_mem_z(FILE *fil_u, c3_z byt_z, const c3_c *cap_c) | ||
{ | ||
c3_assert( 0 != fil_u ); /* ;;: I assume this is important from commit | ||
f975ca908b143fb76c104ecc32cb59317ea5b198: | ||
threads output file pointer through memory | ||
marking and printing. | ||
|
||
If not necessary, we can get rid of | ||
c3_maid_w */ |
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.
The interface is even simpler if we can get rid of the null file assert in _c3_printcap_mem_z
. I think we might be able to, but not sure. See inline comment.
If we can get rid of this, all calls to c3_maid_w
can just call c3_print_mem_w
.
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.
So the question is... when do we want a call to c3_print_mem_w
to crash the process when the output file is null (rather than ignore the print). I would guess never
I welcome function renaming suggestions. |
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 we should just keep the first commit, as you suggested. If we want to refactor in the future we can, but it doesn't seem like there's a compelling reason to refactor (unless I'm missing something).
c3_w _c3_printcap_mem_w (FILE *fil_u, c3_w wor_w, const c3_c *cap_c); | ||
c3_z _c3_printcap_mem_z(FILE *fil_u, c3_z byt_z, const c3_c *cap_c); | ||
|
||
|
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.
There are some Form Feed (U+000C) characters interspersed here and in other places. We should get rid of them.
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.
Form feed characters are good and make code easier to navigate
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.
Oh ok, I just haven't seen them elsewhere in our codebase. Feel free to disregard.
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.
They certainly might not be anywhere else, but I don't think they hurt.
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.
and fyi, I mainly put them here to bracket the pairs of macros which function more as single logical units. I also don't mind their usage to page code into logical sections with header comments
the compelling reason is getting rid of code duplication -- but perhaps that isn't sufficiently compelling. I would also prefer a basic logging interface and this is a step towards that. For instance, fprintfing to stderr, remembering to include the |
There is one semantic change which is that when running say It would certainly be odd if, for instance |
I'm happy to approve a PR with just the first commit to start. Then we can open another one for a refactor. Does that sound good? |
eh I say we just leave it around a little longer. The first commit isn't exactly an urgent fix, so I don't see any advantage to getting that in first. |
Resolves #310
Minimally, I think we should keep the first commit (converting to base 2).
Wondering if the attempt to unify the interfaces/refactor was a waste of time though given how adhoc all the memory printing stuff feels -- so why improve it :-/
It does appear to work well though. Compare output of
|mass
,|pack
, others that print memory, etc.