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

GRIB1 duplicate rule #180

Merged
merged 1 commit into from
Feb 6, 2013
Merged

GRIB1 duplicate rule #180

merged 1 commit into from
Feb 6, 2013

Conversation

bblay
Copy link
Contributor

@bblay bblay commented Oct 29, 2012

No description provided.

@rhattersley
Copy link
Member

What was the impact of the bug? Duplicated coords on the resulting cube? Could be worth a quick test just to help establish some unit test idioms.

@pelson - would you mind shepherding this one? @pp-mo and @bblay have been doing some low level GRIB testing which may help (or not ;-)).

@ghost ghost assigned pelson Oct 30, 2012
@bblay
Copy link
Contributor Author

bblay commented Oct 30, 2012

It raised a ValueError('Duplicate coordinates are not permitted.').

It's a little frustrating that grib.py is largely made to support the current rules system.
From a brief chat with @pp-mo on his testing work I feel that if we could rewrite the load rules as atomic python functions (#182) we'd have an easier time with mocking and testing grib rules.

@bblay
Copy link
Contributor Author

bblay commented Nov 6, 2012

We should wait for the mock gribapi and grib message being developed in #184 before adding a test.

This should allow us to create a mock grib message with timeRangeIndicator == 4 and use the mock gribapi
to run the rules.

@pelson
Copy link
Member

pelson commented Dec 3, 2012

Clearing my assignment. I'd be happy to pick this up once its on the stack, but currently, there is no need to have an individual (and therefore be limited to a single person being able to pick this up) assigned.

@bblay - It looks like there is an action on you here.

Cheers,

@bblay
Copy link
Contributor Author

bblay commented Dec 7, 2012

Test pending #221

@bblay
Copy link
Contributor Author

bblay commented Jan 14, 2013

Rebased.

I don't think there is any test which is appropriate for this ticket.
The duplicate rule has been removed. It is not part of iris.
It seems wrong to check that we no longer have a certain rule in duplicate,
otherwise, shouldn't we do the same for all rules?

Recommend merging without a test in this rare occurrence.

@bblay
Copy link
Contributor Author

bblay commented Jan 17, 2013

rebased onto latest master for more thorough testing

@rhattersley
Copy link
Member

If you're seeing a lot of weird commits in this PR it's because we removed a commit from master and some of the PRs have got themselves confused. A rebase will clear the problem.

NB. It doesn't need a rebase, you can create a new PR with exactly the same commit (i.e. pelson/iris@2bcf972) and it will be just fine. It might be possible to move the head of your PR somewhere else and then back again... but caveat emptor!

@ghost ghost assigned bjlittle Feb 5, 2013
bjlittle added a commit that referenced this pull request Feb 6, 2013
@bjlittle bjlittle merged commit 220a511 into SciTools:master Feb 6, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants