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

Check on parsing state in parsers in the wrong place #141

Closed
aiida-bot opened this issue Apr 29, 2015 · 2 comments · Fixed by #1003
Closed

Check on parsing state in parsers in the wrong place #141

aiida-bot opened this issue Apr 29, 2015 · 2 comments · Fixed by #1003
Assignees
Labels
good first issue Issues that should be relatively easy to fix also for beginning contributors topic/code-structure topic/plugin-system type/accepted feature approved feature request
Milestone

Comments

@aiida-bot
Copy link

Originally reported by: Giovanni Pizzi (Bitbucket: pizzi, GitHub: giovannipizzi)


The CP parser (and I guess many others) has this code inside it (now commented out):

#!python
state = self._calc.get_state()
if state != calc_states.PARSING:
    raise InvalidOperation("Calculation not in {} state"
                           .format(calc_states.PARSING) )

We don't want that this check is done by each plugin. Move this to the main class removing it from all plugins, and think to a way to skip this test if for some reason reparsing is necessary.


@giovannipizzi
Copy link
Member

Decide and document what's the suggested way to write parsers

@DropD DropD added this to the Pre-1.0 release milestone Feb 27, 2017
@szoupanos szoupanos added good first issue Issues that should be relatively easy to fix also for beginning contributors type/feature request status undecided coding-day/done and removed coding-day/wip labels Dec 18, 2017
@DropD DropD added type/accepted feature approved feature request and removed type/feature request status undecided labels Dec 18, 2017
@DropD
Copy link
Contributor

DropD commented Dec 18, 2017

Current state

Current policy is that this check is not required. It is safe to call the parser anyway because it does not store nodes, that is the daemon's responsibility. The parser can be easily tested this way and the daemon will only call the parser on a calculation in parsing state anyway.

To do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Issues that should be relatively easy to fix also for beginning contributors topic/code-structure topic/plugin-system type/accepted feature approved feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants