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

[DEM-831] Compiler warnings in ZIHDAWG8 should be logged or raised. #1522

Merged
merged 7 commits into from
Mar 14, 2019
Merged

[DEM-831] Compiler warnings in ZIHDAWG8 should be logged or raised. #1522

merged 7 commits into from
Mar 14, 2019

Conversation

qSaevar
Copy link
Contributor

@qSaevar qSaevar commented Mar 13, 2019

Changes proposed in this pull request:

  • Compiler warnings in ZIHDAWG8 are caught and logged
  • Compiler warnings can be elevated to errors

@astafan8

for warning_as_error in self._warnings_as_errors:
if re.search(warning_as_error, warning) is not None:
raise CompilerError('Warning treated as an error.', warning)
log.warning(warning)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest using the log attached to the instrument see https://qcodes.github.io/Qcodes/examples/Creating%20Instrument%20Drivers.html#Logging for more info

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️

@codecov
Copy link

codecov bot commented Mar 13, 2019

Codecov Report

Merging #1522 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1522   +/-   ##
=======================================
  Coverage   73.84%   73.84%           
=======================================
  Files          92       92           
  Lines       10459    10459           
=======================================
  Hits         7723     7723           
  Misses       2736     2736

@qSaevar
Copy link
Contributor Author

qSaevar commented Mar 14, 2019

I addressed the comment and tested the branch on hardware. Is there anything else I should do?

Copy link
Contributor

@astafan8 astafan8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This in principle is OK-ish. Depending on how many people wanna use it.

I have two problems with this:

  • filtering with regexp is absolutely not convenient in this case, and requires some effort to test/debug. i wish these warnings had "id" by which one could decide to throw an exception with it or not.
  • if there are "errors", the only the first one is raised as an exception, and others are not included. I'd suggest that a more convenient way is to collect all "errors" and raise them as a single exception.

['compiler']['sourcestring'][0]) > 0:
time.sleep(0.1)
['compiler']['sourcestring'][0]) > 0:
time.sleep(0.01)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please make at least a private attribute of the driver class out of this value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️

@@ -39,6 +53,19 @@ def __init__(self, name: str, device_id: str, **kwargs) -> None:
self.awg_module.execute()
node_tree = self.download_device_node_tree()
self.create_parameters_from_node_tree(node_tree)
self._warnings_as_errors: List[str] = []

def elevate_compiler_warning_to_error(self, *warnings: str) -> None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since there is this "add" functionality, i'd expect also a function for "removing" an already added warning so that it's treated again as a warning, right?)

to make it even easier, instead of creating the "add" and "remove" functions, i'd just make the _warnings_as_errors list "public" and write smth in the docs or the example notebook on how to use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️

@qSaevar
Copy link
Contributor Author

qSaevar commented Mar 14, 2019

filtering with regexp is absolutely not convenient in this case, and requires some effort to test/debug. i wish these warnings had "id" by which one could decide to throw an exception with it or not.

Filtering using regular expressions is needed as the status string has more info then just warnings. It is the output from the compiler and is only accessible as a single string. What type of "id" are you thinking about?

if there are "errors", the only the first one is raised as an exception, and others are not included. I'd suggest that a more convenient way is to collect all "errors" and raise them as a single exception.

That I will do.

@qSaevar
Copy link
Contributor Author

qSaevar commented Mar 14, 2019

@astafan8 I addressed the comments except the one with the error "ids".

Copy link
Contributor

@astafan8 astafan8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost there :)

qcodes/instrument_drivers/ZI/ZIHDAWG8.py Outdated Show resolved Hide resolved
qcodes/instrument_drivers/ZI/ZIHDAWG8.py Outdated Show resolved Hide resolved
qcodes/instrument_drivers/ZI/ZIHDAWG8.py Outdated Show resolved Hide resolved
astafan8 and others added 2 commits March 14, 2019 15:13
if len(errors) > 0:
raise CompilerError('Warning treated as an error.', *errors)

[self.log.warning(warning) for warning in warnings]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, and now it would be great as a user to get the "warning" warnings before the "error" warnings so that you get the "full compiler response", not just the "error" part in case there are "error" warnings. Fair wish? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair

@qSaevar
Copy link
Contributor Author

qSaevar commented Mar 14, 2019

I moved the logging of the warnings back into the for loop, but only log those that are not treated as errors.

Copy link
Contributor

@astafan8 astafan8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Brilliant! Thank you! Once the CI is done, i'll merge.

@astafan8 astafan8 merged commit 75fbea4 into microsoft:master Mar 14, 2019
@qSaevar qSaevar deleted the feature/DEM-831/Compiler-warnings-should-be-caught branch March 14, 2019 16:15
giulioungaretti pushed a commit that referenced this pull request Mar 14, 2019
Merge: ebda0a8 6495a4a
Author: Mikhail Astafev <astafan8@gmail.com>

    Merge pull request #1522 from qutech-sd/feature/DEM-831/Compiler-warnings-should-be-caught
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants