I removed the branch bugfix-1035, or at least tried to, but there is
one lingering commit. Sent in a support ticket cuz it won't seem to
strip properly, but I think as of f7ccf8f8c2ac things should be in
I've gone through today and marked several issues as resolved that were
fixed with recent PRs. It'd probably be good if several of us went through
and looked at them, to see if there are any major bugfixes that we probably
ought to resolve before 3.2 release, but only if they're simple enough that
we can be certain we don't introduce other problems.
We had our second weekly PR review hangout today and I wanted to draw your
attention to a few things. Firstly, thanks once again to Hilary for
organizing this. The streak is at 2, a record for the yt project.
Secondly, while it has only been two weeks, I think that this is working
spectacularly. Every PR not listed as a work in progress received
attention with many being accepted and the rest getting comments on what
needs to happen to get them accepted. Way to go, everyone!
In other big news, the enormous volume render refactor PR has been pulled
into the main yt repository and will live under a separate head bookmarked
"experimental" until it is totally ready for primetime. This should make
development move forward more smoothly as it will allow developers to issue
PRs directly to yt instead of to Sam Skillman's fork, which was the origin
of the original PR. If you'd like to try it out, just "hg up experimental"
and you're there. Kudos to everyone making that happen.
Finally, we turn to our top story this evening. We are on track for
releasing yt-3.2 next Friday, July 24. I had originally suggested we do
this tomorrow, but we need a cooling off period after all the PRs that were
accepted today. So, on that note, as of right now, we are calling a freeze
on accepting PRs that contain new features until after 3.2 has been
released. Bugfix PRs may still be pulled in before that, provided they are
not overly complicated.
So there you have it. Thanks, everyone! For what? For everything!
New issue 1044: Athena parsing is broken in python3
This can be reproduced in python3 by doing `yt load ShockCloud/id0/Cloud.0050.vtk` at the command line.
The issue occurs in the `parse_line` function in `yt/frontends/athena/data_structures.py`. Here is an abbreviated version of that function that illustrates the exact issue:
def parse_line(line, grid):
# grid is a dictionary
splitup = line.strip().split()
# *** snip ***
elif chk23("SCALARS") in splitup:
field = str23(splitup)
grid['read_field'] = field
grid['read_type'] = 'scalar'
# *** snip ***
Since `line` is a byte sequence, `line.strip().split()` returns a list of byte sequences. `chk23("SCALARS")` does not return a byte sequence, instead returning a unicode string in python3.
This means that grid['read_field'] never gets filled out, so the loop in `_parse_parameter_file` can never be terminated.
The fix is to be consistent in comparing bytes with bytes or strings with strings. Since @jzuhone was the last person to look at this I'm going to assign the issue to him.
Nathan and I just met briefly to discuss backporting all bugfix PRs from
the development branch to stable so as to do a minor release. This has
become absolutely necessary as a large number of bugs have appeared and
been fixed since the last release, which was nearly 6 months ago. By my
rough estimate, there have been about 200 PRs accepted since the last
release, with a large fraction of them being bug fixes. Therefore, it
seemed to both Nathan and I that there were simply too many changesets that
need to be picked out of dev and transplanted to stable for such an
operation to be feasible.
Instead, a far simpler solution is to bite the bullet and do a 3.2 release
with everything currently in dev. Fortunately, as we require passing tests
and documentation of new features, this would require relatively little
effort. Most of the work is cleaning up errors in the docs build, for
which Nathan is filing tickets as I write this.
I want to be clear that we desperately need a new release with the number
of bugs that have been fixed since the last one. If we do not do this,
then someone else needs to step up and backport all those bugfixes to
For now, can I please get a +-1 on whether you agree with this proposal.
If this meets with approval, then I will coordinate taking the next steps.