Conversation
7354731 to
e937e47
Compare
il-steffen
left a comment
There was a problem hiding this comment.
There's a few places where the auto-formating hurts readability...some places where we really should not do this without prior refactoring, I think...
| node.node_struct["info"]["trimmed"] = True | ||
| node.set_score(self.scheduler.score_speed(node)) | ||
| if results.get("performance"): | ||
| oldperf = node.get_initial_performance() |
There was a problem hiding this comment.
breaks the following out-commented print...either remove all or comment all?
There was a problem hiding this comment.
the print() could be converted to logger.debug()
There was a problem hiding this comment.
commented-out code is dead code,
I can convert it to logger.debug() for convenience.
There was a problem hiding this comment.
In my last update, I uncommented the print() dead code, and turned it into a logger.debug() statement, keeping the 2 lines above of course
|
one small tidbid....the changes look fine otherwise but we should triple-check that the redqueen changes are really correct (eg. no side-effect to the called functions..) |
The only way to ensure that redqueen works is to have unit tests, otherwise we can't allow ourselves a simple refactoring because we are afraid of silent breaking changes. I've seen the redqueen_mut.py test file. |
I never ran this code, just kept it around in case we ever get to this kind of testing. I think we can use it with input from a random fuzzing session to at least produce some known-good test vectors. This would be far from actual functional testing, but better than looking for bugs through manual execution.. The inputs for this function are probably the files generated at $workdir/redqueen* during an active fuzzing run. |
New makefile targets
lint: runs flake8lint_check: runs flake8 and count the number of errorsTools used:
Configuration
There are so many lint warnings and error that it's a better strategy to select and enable lint categories one by one in multiple PRs.