Fix three defects in tools/submission/log_parser.py - #2662
Conversation
get_dict built its result dict and never returned it, so every caller received None. Its duplicate-key warning branch formatted an undefined `key`, raising NameError as soon as a log contained the same key twice. And dump opened an undefined `log_path` rather than its own output_path parameter, so it raised NameError on every call. Return the dict, format message["key"], and write to output_path.
|
MLCommons CLA bot: |
|
Could a maintainer advise on the right way to sign the individual CLA? The documented path currently loops back on itself.
So there is nowhere to actually submit a GitHub ID, and as an individual contributor rather than a member-organization employee I don't have an organizational address to enter. I'm happy to sign — just need a working link or an address to send it to. GitHub ID is Once it's sorted I'll comment |
|
@David-Wu1119 I'm not fully sure of the current process as they have been changed recently. But I expect that the bot comment is the most up to date one and in case of any issues, support email is the best place to go. As an individual contributor - once you sign up as a member you can provide the GitHub id. I'm not sure if currently the GitHub id is automatically taken from the member email in which case the signup email must be linked to the GitHub account. |
Summary
Three defects in
tools/submission/log_parser.py, all inMLPerfLog:1.
get_dict()never returns. It buildsresultand falls off the end, so every caller getsNone:2. The duplicate-key warning references an undefined
key. It formatskeyrather thanmessage["key"], so the moment a log contains the same key twice,get_dict()raises:3.
dump()opens an undefinedlog_path. The parameter is calledoutput_path, sodump()raisesNameErroron every call.ruff --select F821flags both undefined names.Verification
Exercising all three paths on a small
MLPerfLogwith a deliberate duplicate key:Before —
After —
So the first-one-wins behaviour the docstring promises now actually holds, the warning names the offending key, and
dump()writes to the path it was given.Notes
ruff --select F821is clean on the file afterwards. I kept the existing wording of the warning, including the "Emprically" typo, so the diff stays limited to the defects — happy to fix the spelling too if you'd like it in the same PR.