Hi all, On Friday, Anthony submitted a PR to the yt-3.0 branch: https://bitbucket.org/yt_analysis/yt-3.0/pull-request/4/na-is-dead-long-live... This PR is pretty invasive, and done by regular expressions. Basically, for a long time we've been sticking with a convention I started using about ... six years ago ... when NumArray was the dominant array language. (Or when I was still too removed from Python's scientific community to see otherwise.) The array library was shortened to 'na'. Almost immediately after, NumPy took over and while we switched to NumPy we never updated the shorthand in the Python code to 'np'. (The Cython code always uses 'np') Most python tutorials use np instead of numpy, and I'd like to encourage best practices in yt as well as suggest we try to fit into the broader ecosystem of packages. Anyway, this is kind of a bandaid that needs to be ripped off at some point, and I think it's appropriate to discuss now. I see three options, which basically break down on levels of disruption and ease of the dual-lines of development we currently have. 1) Put this PR (which applies only to 3.0) on hold. This way, merging from 2.x to 3.0 can proceed easily, and the disruption is completely pushed off for a bit. 2) Accept the PR. This increases the burden on me for merging considerably, and it would fall on me. Any file where both a numpy line and another line are changed would throw a conflict that I'd have to manually resolve. But, because it would just be in the 3.0 line, disruption would be kept to a minimum. 3) Accept the PR *but* also mandate that we apply it to the main repository's development branch (2.x). This would be the most disruptive, but it would also keep merging difficulty to a minimum. As a compatibility layer, we'll keep "na" in the yt.mods namespace, which means my_plugins.py files would still work, as would existing scripts. Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future. What do people think -- of the three options, which is your favorite, and do you have strong feelings against any one option? -Matt
I'd go with #3. On Mon, Aug 27, 2012 at 10:08 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
On Friday, Anthony submitted a PR to the yt-3.0 branch:
https://bitbucket.org/yt_analysis/yt-3.0/pull-request/4/na-is-dead-long-live...
This PR is pretty invasive, and done by regular expressions. Basically, for a long time we've been sticking with a convention I started using about ... six years ago ... when NumArray was the dominant array language. (Or when I was still too removed from Python's scientific community to see otherwise.) The array library was shortened to 'na'. Almost immediately after, NumPy took over and while we switched to NumPy we never updated the shorthand in the Python code to 'np'. (The Cython code always uses 'np') Most python tutorials use np instead of numpy, and I'd like to encourage best practices in yt as well as suggest we try to fit into the broader ecosystem of packages.
Anyway, this is kind of a bandaid that needs to be ripped off at some point, and I think it's appropriate to discuss now. I see three options, which basically break down on levels of disruption and ease of the dual-lines of development we currently have.
1) Put this PR (which applies only to 3.0) on hold. This way, merging from 2.x to 3.0 can proceed easily, and the disruption is completely pushed off for a bit. 2) Accept the PR. This increases the burden on me for merging considerably, and it would fall on me. Any file where both a numpy line and another line are changed would throw a conflict that I'd have to manually resolve. But, because it would just be in the 3.0 line, disruption would be kept to a minimum. 3) Accept the PR *but* also mandate that we apply it to the main repository's development branch (2.x). This would be the most disruptive, but it would also keep merging difficulty to a minimum. As a compatibility layer, we'll keep "na" in the yt.mods namespace, which means my_plugins.py files would still work, as would existing scripts.
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
What do people think -- of the three options, which is your favorite, and do you have strong feelings against any one option?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
My vote is #3, since otherwise we'll be faced with the same trilemma later if we don't. John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 773-758-0172 jzuhone@gmail.com john.zuhone@nasa.gov On Aug 27, 2012, at 10:08 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
On Friday, Anthony submitted a PR to the yt-3.0 branch:
https://bitbucket.org/yt_analysis/yt-3.0/pull-request/4/na-is-dead-long-live...
This PR is pretty invasive, and done by regular expressions. Basically, for a long time we've been sticking with a convention I started using about ... six years ago ... when NumArray was the dominant array language. (Or when I was still too removed from Python's scientific community to see otherwise.) The array library was shortened to 'na'. Almost immediately after, NumPy took over and while we switched to NumPy we never updated the shorthand in the Python code to 'np'. (The Cython code always uses 'np') Most python tutorials use np instead of numpy, and I'd like to encourage best practices in yt as well as suggest we try to fit into the broader ecosystem of packages.
Anyway, this is kind of a bandaid that needs to be ripped off at some point, and I think it's appropriate to discuss now. I see three options, which basically break down on levels of disruption and ease of the dual-lines of development we currently have.
1) Put this PR (which applies only to 3.0) on hold. This way, merging from 2.x to 3.0 can proceed easily, and the disruption is completely pushed off for a bit. 2) Accept the PR. This increases the burden on me for merging considerably, and it would fall on me. Any file where both a numpy line and another line are changed would throw a conflict that I'd have to manually resolve. But, because it would just be in the 3.0 line, disruption would be kept to a minimum. 3) Accept the PR *but* also mandate that we apply it to the main repository's development branch (2.x). This would be the most disruptive, but it would also keep merging difficulty to a minimum. As a compatibility layer, we'll keep "na" in the yt.mods namespace, which means my_plugins.py files would still work, as would existing scripts.
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
What do people think -- of the three options, which is your favorite, and do you have strong feelings against any one option?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
1) +0 2) -1 3) +1 Rip the bandaid. On Mon, Aug 27, 2012 at 8:25 AM, John ZuHone <jzuhone@gmail.com> wrote:
My vote is #3, since otherwise we'll be faced with the same trilemma later if we don't.
John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 773-758-0172 jzuhone@gmail.com john.zuhone@nasa.gov
On Aug 27, 2012, at 10:08 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
On Friday, Anthony submitted a PR to the yt-3.0 branch:
https://bitbucket.org/yt_analysis/yt-3.0/pull-request/4/na-is-dead-long-live...
This PR is pretty invasive, and done by regular expressions. Basically, for a long time we've been sticking with a convention I started using about ... six years ago ... when NumArray was the dominant array language. (Or when I was still too removed from Python's scientific community to see otherwise.) The array library was shortened to 'na'. Almost immediately after, NumPy took over and while we switched to NumPy we never updated the shorthand in the Python code to 'np'. (The Cython code always uses 'np') Most python tutorials use np instead of numpy, and I'd like to encourage best practices in yt as well as suggest we try to fit into the broader ecosystem of packages.
Anyway, this is kind of a bandaid that needs to be ripped off at some point, and I think it's appropriate to discuss now. I see three options, which basically break down on levels of disruption and ease of the dual-lines of development we currently have.
1) Put this PR (which applies only to 3.0) on hold. This way, merging from 2.x to 3.0 can proceed easily, and the disruption is completely pushed off for a bit. 2) Accept the PR. This increases the burden on me for merging considerably, and it would fall on me. Any file where both a numpy line and another line are changed would throw a conflict that I'd have to manually resolve. But, because it would just be in the 3.0 line, disruption would be kept to a minimum. 3) Accept the PR *but* also mandate that we apply it to the main repository's development branch (2.x). This would be the most disruptive, but it would also keep merging difficulty to a minimum. As a compatibility layer, we'll keep "na" in the yt.mods namespace, which means my_plugins.py files would still work, as would existing scripts.
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
What do people think -- of the three options, which is your favorite, and do you have strong feelings against any one option?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 on #3. On Mon, Aug 27, 2012 at 10:27 AM, Sam Skillman <samskillman@gmail.com>wrote:
1) +0 2) -1 3) +1
Rip the bandaid.
On Mon, Aug 27, 2012 at 8:25 AM, John ZuHone <jzuhone@gmail.com> wrote:
My vote is #3, since otherwise we'll be faced with the same trilemma later if we don't.
John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 773-758-0172 jzuhone@gmail.com john.zuhone@nasa.gov
On Aug 27, 2012, at 10:08 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
On Friday, Anthony submitted a PR to the yt-3.0 branch:
https://bitbucket.org/yt_analysis/yt-3.0/pull-request/4/na-is-dead-long-live...
This PR is pretty invasive, and done by regular expressions. Basically, for a long time we've been sticking with a convention I started using about ... six years ago ... when NumArray was the dominant array language. (Or when I was still too removed from Python's scientific community to see otherwise.) The array library was shortened to 'na'. Almost immediately after, NumPy took over and while we switched to NumPy we never updated the shorthand in the Python code to 'np'. (The Cython code always uses 'np') Most python tutorials use np instead of numpy, and I'd like to encourage best practices in yt as well as suggest we try to fit into the broader ecosystem of packages.
Anyway, this is kind of a bandaid that needs to be ripped off at some point, and I think it's appropriate to discuss now. I see three options, which basically break down on levels of disruption and ease of the dual-lines of development we currently have.
1) Put this PR (which applies only to 3.0) on hold. This way, merging from 2.x to 3.0 can proceed easily, and the disruption is completely pushed off for a bit. 2) Accept the PR. This increases the burden on me for merging considerably, and it would fall on me. Any file where both a numpy line and another line are changed would throw a conflict that I'd have to manually resolve. But, because it would just be in the 3.0 line, disruption would be kept to a minimum. 3) Accept the PR *but* also mandate that we apply it to the main repository's development branch (2.x). This would be the most disruptive, but it would also keep merging difficulty to a minimum. As a compatibility layer, we'll keep "na" in the yt.mods namespace, which means my_plugins.py files would still work, as would existing scripts.
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
What do people think -- of the three options, which is your favorite, and do you have strong feelings against any one option?
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, my thoughts were that big changes like this should come with a point release. In light of the technical details Matt has given, it appears that it's best to do everything at once. So, #3 is my vote. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
Stephen, I would normally agree but since there hopefully won't be any changes as seen from the user perspective I think we should be all right. John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 773-758-0172 jzuhone@gmail.com john.zuhone@nasa.gov On Aug 27, 2012, at 10:38 AM, Stephen Skory <s@skory.us> wrote:
Hi all,
my thoughts were that big changes like this should come with a point release. In light of the technical details Matt has given, it appears that it's best to do everything at once. So, #3 is my vote.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines: find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \; should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
Hello All, Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best. Be Well Anthony On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com>wrote:
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time. In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this: http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204 In short, by applying to both, we're going to be okay. :) -Matt On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that? And, do we want to merge to stable so that any big bug fixes get applied there before doing so? -Matt On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Strongly -1 on merging to stable as it will break user scripts. I know I'll have to update mine wherever I use the numpy imported along with yt.mods. -Nathan On 8/31/12 7:06 PM, Matthew Turk wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that? And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future. Hi,
On 27.08.2012 16:08, Matthew Turk wrote: there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Nathan, The question is if we should be merging to stable before applying the na/np transformation. Additionally, as noted in the previous email, we'll retain importing "na" in yt.mods for the indefinite future. -Matt On Fri, Aug 31, 2012 at 7:08 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Strongly -1 on merging to stable as it will break user scripts. I know I'll have to update mine wherever I use the numpy imported along with yt.mods.
-Nathan
On 8/31/12 7:06 PM, Matthew Turk wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that? And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1 on big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so, Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik < xarthisius.kk@gmail.com> wrote:
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1
on
big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
PR #258 sent. On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik < xarthisius.kk@gmail.com> wrote:
On 27.08.2012 16:08, Matthew Turk wrote:
Because this could be disruptive for any major, outstanding forks, I also think it needs to be discussed here. (I'm actually kind of -1
on
big discussions happening in pull requests.) My vote is for #3. I'd rather get this over with, since we all know it probably ought to happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I'm going to run tests here. And I am also going to wait until Monday to actually do the merge, because I know a few people who might have thoughts on this are away today but back this weekend. Nathan, does keeping na in mods solve the issue you were referencing? I believe the rest should all just be internal -- this change won't affect any userspace scripts, but instead only internal imports. The reason I suggested the merge in advance was to encourage any existing bug fixes to be ported back to stable, as from here on out the patches will likely need to be manually applied. -Matt On Fri, Aug 31, 2012 at 12:14 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
PR #258 sent.
On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
On 27.08.2012 16:08, Matthew Turk wrote: > Because this could be disruptive for any major, outstanding forks, > I > also think it needs to be discussed here. (I'm actually kind of -1 > on > big discussions happening in pull requests.) My vote is for #3. > I'd > rather get this over with, since we all know it probably ought to > happen at some point in the future.
Hi, there's a way to minimize the disruption on any outstanding forks, namely to automate the process. If we use the same "tool" on both main repo and the fork, the difference should be close to none. In this case something along the lines:
find . -name "*.py" \ -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ -e "s/numpy as na/numpy as np/g" -i {} \;
should do the trick. I haven't check yet if that reproduces Anthony's PR so use it carefully ;) Cheers, Kacper
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Also, I've accepted the 3.0 pull request. Thanks, Anthony! On Fri, Aug 31, 2012 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm going to run tests here. And I am also going to wait until Monday to actually do the merge, because I know a few people who might have thoughts on this are away today but back this weekend.
Nathan, does keeping na in mods solve the issue you were referencing? I believe the rest should all just be internal -- this change won't affect any userspace scripts, but instead only internal imports. The reason I suggested the merge in advance was to encourage any existing bug fixes to be ported back to stable, as from here on out the patches will likely need to be manually applied.
-Matt
On Fri, Aug 31, 2012 at 12:14 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
PR #258 sent.
On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote: > > On 27.08.2012 16:08, Matthew Turk wrote: > > Because this could be disruptive for any major, outstanding forks, > > I > > also think it needs to be discussed here. (I'm actually kind of -1 > > on > > big discussions happening in pull requests.) My vote is for #3. > > I'd > > rather get this over with, since we all know it probably ought to > > happen at some point in the future. > > Hi, > there's a way to minimize the disruption on any outstanding forks, > namely to automate the process. If we use the same "tool" on both > main > repo and the fork, the difference should be close to none. > In this case something along the lines: > > find . -name "*.py" \ > -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ > -e "s/numpy as na/numpy as np/g" -i {} \; > > should do the trick. I haven't check yet if that reproduces Anthony's > PR > so use it carefully ;) > Cheers, > Kacper > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hey Matt, Yes, sorry for jumping in without reading the older messages too closely. Long live np! Nathan On Sep 1, 2012, at 1:43 AM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm going to run tests here. And I am also going to wait until Monday to actually do the merge, because I know a few people who might have thoughts on this are away today but back this weekend.
Nathan, does keeping na in mods solve the issue you were referencing? I believe the rest should all just be internal -- this change won't affect any userspace scripts, but instead only internal imports. The reason I suggested the merge in advance was to encourage any existing bug fixes to be ported back to stable, as from here on out the patches will likely need to be manually applied.
-Matt
On Fri, Aug 31, 2012 at 12:14 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
PR #258 sent.
On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello All,
Obviously, I am +1 for #3 and +0 on #2 (no need to create a maintenance headache if you don't have to). I originally did this in the 3.0 fork just because I thought it was more of a sandbox than the 2.x series. I am also +0 on #1, if that is what is best.
Be Well Anthony
On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote: > > On 27.08.2012 16:08, Matthew Turk wrote: >> Because this could be disruptive for any major, outstanding forks, >> I >> also think it needs to be discussed here. (I'm actually kind of -1 >> on >> big discussions happening in pull requests.) My vote is for #3. >> I'd >> rather get this over with, since we all know it probably ought to >> happen at some point in the future. > > Hi, > there's a way to minimize the disruption on any outstanding forks, > namely to automate the process. If we use the same "tool" on both > main > repo and the fork, the difference should be close to none. > In this case something along the lines: > > find . -name "*.py" \ > -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ > -e "s/numpy as na/numpy as np/g" -i {} \; > > should do the trick. I haven't check yet if that reproduces Anthony's > PR > so use it carefully ;) > Cheers, > Kacper > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, I've merged to the tip of the development repository. The question is now, do we want to merge to stable from just before the na/np switchover for an intermediate backport of fixes? Or should we just push for a faster release cycle on a potential 2.5? The main changes (last one month or so) include: * Fortran kd-tree building * Finding outputs fix for cosmology analysis * Merger tree speedup * MQK's fixes for cylindrical coordinates in cartesian domains * Athena frontend (nice, big feature) * Enzo 1D/2D fixes * Fixes for FLASH 1D/2D datasets * load_uniform_data (which is a nice, big feature) * Grid decomposition * GDF writer (nice, big feature) * IO staging * Some good enhancements and fixes for the callbacks and plot window * Colorbar fix for healpix camera Some of these are things that really warrant a new release, like Athena and l_u_g, so I am tempted to suggest we hold off and go for 2.5 sometime soon... [+-][01] on merging to stable? The hash of the pre-np changeset is b45aa6c3c142. -Matt On Fri, Aug 31, 2012 at 9:02 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hey Matt,
Yes, sorry for jumping in without reading the older messages too closely.
Long live np!
Nathan
On Sep 1, 2012, at 1:43 AM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm going to run tests here. And I am also going to wait until Monday to actually do the merge, because I know a few people who might have thoughts on this are away today but back this weekend.
Nathan, does keeping na in mods solve the issue you were referencing? I believe the rest should all just be internal -- this change won't affect any userspace scripts, but instead only internal imports. The reason I suggested the merge in advance was to encourage any existing bug fixes to be ported back to stable, as from here on out the patches will likely need to be manually applied.
-Matt
On Fri, Aug 31, 2012 at 12:14 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
PR #258 sent.
On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Nearly everyone who has replied so far is on board with the third option, which is to apply the same change to both. Anthony and Kacper also had a discussion in the PR about the cosmology routines, which seem to be (!!!) non-functional in some particular configurations of the universe. I'll suggest that we wait until Wednesday, and if nobody objects by then, we accept this PR and then also a similar one for the dev branch. I'd prefer we not apply these changes to the stable branch at this time.
In IRC, Martin Geisler also pointed me at these StackOverflow questions which address merges and workflows like this:
http://stackoverflow.com/a/9533927/110204 http://stackoverflow.com/a/9500764/110204
In short, by applying to both, we're going to be okay. :)
-Matt
On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com> wrote: > Hello All, > > Obviously, I am +1 for #3 and +0 on #2 (no need to create a > maintenance > headache if you don't have to). I originally did this in the 3.0 fork > just > because > I thought it was more of a sandbox than the 2.x series. I am also +0 > on #1, > if that is what is best. > > Be Well > Anthony > > > On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik > <xarthisius.kk@gmail.com> > wrote: >> >> On 27.08.2012 16:08, Matthew Turk wrote: >>> Because this could be disruptive for any major, outstanding forks, >>> I >>> also think it needs to be discussed here. (I'm actually kind of -1 >>> on >>> big discussions happening in pull requests.) My vote is for #3. >>> I'd >>> rather get this over with, since we all know it probably ought to >>> happen at some point in the future. >> >> Hi, >> there's a way to minimize the disruption on any outstanding forks, >> namely to automate the process. If we use the same "tool" on both >> main >> repo and the fork, the difference should be close to none. >> In this case something along the lines: >> >> find . -name "*.py" \ >> -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ >> -e "s/numpy as na/numpy as np/g" -i {} \; >> >> should do the trick. I haven't check yet if that reproduces Anthony's >> PR >> so use it carefully ;) >> Cheers, >> Kacper >> >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I think we should go for 2.5 release. BTW, an Athena user just found a bug where certain simulations that don't have equal sized grids will not work. I didn't think this was possible but it turns out it is so they or I will be addressing that in the coming days. If the release is >1month, I would also like to push in some rendering/AMRKDTree improvements. If it <1month, I don't think I'll get to it. Sam On Mon, Sep 10, 2012 at 11:55 AM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
I've merged to the tip of the development repository. The question is now, do we want to merge to stable from just before the na/np switchover for an intermediate backport of fixes? Or should we just push for a faster release cycle on a potential 2.5?
The main changes (last one month or so) include:
* Fortran kd-tree building * Finding outputs fix for cosmology analysis * Merger tree speedup * MQK's fixes for cylindrical coordinates in cartesian domains * Athena frontend (nice, big feature) * Enzo 1D/2D fixes * Fixes for FLASH 1D/2D datasets * load_uniform_data (which is a nice, big feature) * Grid decomposition * GDF writer (nice, big feature) * IO staging * Some good enhancements and fixes for the callbacks and plot window * Colorbar fix for healpix camera
Some of these are things that really warrant a new release, like Athena and l_u_g, so I am tempted to suggest we hold off and go for 2.5 sometime soon...
[+-][01] on merging to stable? The hash of the pre-np changeset is b45aa6c3c142.
-Matt
On Fri, Aug 31, 2012 at 9:02 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hey Matt,
Yes, sorry for jumping in without reading the older messages too closely.
Long live np!
Nathan
On Sep 1, 2012, at 1:43 AM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm going to run tests here. And I am also going to wait until Monday to actually do the merge, because I know a few people who might have thoughts on this are away today but back this weekend.
Nathan, does keeping na in mods solve the issue you were referencing? I believe the rest should all just be internal -- this change won't affect any userspace scripts, but instead only internal imports. The reason I suggested the merge in advance was to encourage any existing bug fixes to be ported back to stable, as from here on out the patches will likely need to be manually applied.
-Matt
On Fri, Aug 31, 2012 at 12:14 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
PR #258 sent.
On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
Okay, looks like everybody's pretty much in favor. Anthony, would it be possible to run the script on the tip of the 2.x repository and issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
And, do we want to merge to stable so that any big bug fixes get applied there before doing so?
-Matt
On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk <matthewturk@gmail.com
wrote: > Nearly everyone who has replied so far is on board with the third > option, which is to apply the same change to both. Anthony and Kacper > also had a discussion in the PR about the cosmology routines, which > seem to be (!!!) non-functional in some particular configurations of > the universe. I'll suggest that we wait until Wednesday, and if > nobody objects by then, we accept this PR and then also a similar one > for the dev branch. I'd prefer we not apply these changes to the > stable branch at this time. > > In IRC, Martin Geisler also pointed me at these StackOverflow > questions which address merges and workflows like this: > > http://stackoverflow.com/a/9533927/110204 > http://stackoverflow.com/a/9500764/110204 > > In short, by applying to both, we're going to be okay. :) > > -Matt > > On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz <scopatz@gmail.com
> wrote: >> Hello All, >> >> Obviously, I am +1 for #3 and +0 on #2 (no need to create a >> maintenance >> headache if you don't have to). I originally did this in the 3.0 fork >> just >> because >> I thought it was more of a sandbox than the 2.x series. I am also +0 >> on #1, >> if that is what is best. >> >> Be Well >> Anthony >> >> >> On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik >> <xarthisius.kk@gmail.com> >> wrote: >>> >>> On 27.08.2012 16:08, Matthew Turk wrote: >>>> Because this could be disruptive for any major, outstanding forks, >>>> I >>>> also think it needs to be discussed here. (I'm actually kind of -1 >>>> on >>>> big discussions happening in pull requests.) My vote is for #3. >>>> I'd >>>> rather get this over with, since we all know it probably ought to >>>> happen at some point in the future. >>> >>> Hi, >>> there's a way to minimize the disruption on any outstanding forks, >>> namely to automate the process. If we use the same "tool" on both >>> main >>> repo and the fork, the difference should be close to none. >>> In this case something along the lines: >>> >>> find . -name "*.py" \ >>> -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ >>> -e "s/numpy as na/numpy as np/g" -i {} \; >>> >>> should do the trick. I haven't check yet if that reproduces Anthony's >>> PR >>> so use it carefully ;) >>> Cheers, >>> Kacper >>> >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Sam, On Mon, Sep 10, 2012 at 2:07 PM, Sam Skillman <samskillman@gmail.com> wrote:
I think we should go for 2.5 release.
Okay. If we do that, I'd push for a 2.5 release to coincide with full functionality of 3.0. I'm still trying to aim for this being relatively soon, so we can start migrating development there.
BTW, an Athena user just found a bug where certain simulations that don't have equal sized grids will not work. I didn't think this was possible but it turns out it is so they or I will be addressing that in the coming days.
If the release is >1month, I would also like to push in some rendering/AMRKDTree improvements. If it <1month, I don't think I'll get to it.
I think it will be >1 month.
Sam
On Mon, Sep 10, 2012 at 11:55 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
I've merged to the tip of the development repository. The question is now, do we want to merge to stable from just before the na/np switchover for an intermediate backport of fixes? Or should we just push for a faster release cycle on a potential 2.5?
The main changes (last one month or so) include:
* Fortran kd-tree building * Finding outputs fix for cosmology analysis * Merger tree speedup * MQK's fixes for cylindrical coordinates in cartesian domains * Athena frontend (nice, big feature) * Enzo 1D/2D fixes * Fixes for FLASH 1D/2D datasets * load_uniform_data (which is a nice, big feature) * Grid decomposition * GDF writer (nice, big feature) * IO staging * Some good enhancements and fixes for the callbacks and plot window * Colorbar fix for healpix camera
Some of these are things that really warrant a new release, like Athena and l_u_g, so I am tempted to suggest we hold off and go for 2.5 sometime soon...
[+-][01] on merging to stable? The hash of the pre-np changeset is b45aa6c3c142.
-Matt
On Fri, Aug 31, 2012 at 9:02 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hey Matt,
Yes, sorry for jumping in without reading the older messages too closely.
Long live np!
Nathan
On Sep 1, 2012, at 1:43 AM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm going to run tests here. And I am also going to wait until Monday to actually do the merge, because I know a few people who might have thoughts on this are away today but back this weekend.
Nathan, does keeping na in mods solve the issue you were referencing? I believe the rest should all just be internal -- this change won't affect any userspace scripts, but instead only internal imports. The reason I suggested the merge in advance was to encourage any existing bug fixes to be ported back to stable, as from here on out the patches will likely need to be manually applied.
-Matt
On Fri, Aug 31, 2012 at 12:14 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
PR #258 sent.
On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk@gmail.com> wrote: > > Hi all, > > Okay, looks like everybody's pretty much in favor. Anthony, would > it > be possible to run the script on the tip of the 2.x repository and > issue a PR for that?
Yup, I'll do so within the next hour or so,
Be Well Anthony
> > And, do we want to merge to stable so that any > big bug fixes get applied there before doing so? > > -Matt > > On Mon, Aug 27, 2012 at 2:30 PM, Matthew Turk > <matthewturk@gmail.com> > wrote: >> Nearly everyone who has replied so far is on board with the third >> option, which is to apply the same change to both. Anthony and >> Kacper >> also had a discussion in the PR about the cosmology routines, which >> seem to be (!!!) non-functional in some particular configurations >> of >> the universe. I'll suggest that we wait until Wednesday, and if >> nobody objects by then, we accept this PR and then also a similar >> one >> for the dev branch. I'd prefer we not apply these changes to the >> stable branch at this time. >> >> In IRC, Martin Geisler also pointed me at these StackOverflow >> questions which address merges and workflows like this: >> >> http://stackoverflow.com/a/9533927/110204 >> http://stackoverflow.com/a/9500764/110204 >> >> In short, by applying to both, we're going to be okay. :) >> >> -Matt >> >> On Mon, Aug 27, 2012 at 1:47 PM, Anthony Scopatz >> <scopatz@gmail.com> >> wrote: >>> Hello All, >>> >>> Obviously, I am +1 for #3 and +0 on #2 (no need to create a >>> maintenance >>> headache if you don't have to). I originally did this in the 3.0 >>> fork >>> just >>> because >>> I thought it was more of a sandbox than the 2.x series. I am also >>> +0 >>> on #1, >>> if that is what is best. >>> >>> Be Well >>> Anthony >>> >>> >>> On Mon, Aug 27, 2012 at 9:54 AM, Kacper Kowalik >>> <xarthisius.kk@gmail.com> >>> wrote: >>>> >>>> On 27.08.2012 16:08, Matthew Turk wrote: >>>>> Because this could be disruptive for any major, outstanding >>>>> forks, >>>>> I >>>>> also think it needs to be discussed here. (I'm actually kind of >>>>> -1 >>>>> on >>>>> big discussions happening in pull requests.) My vote is for #3. >>>>> I'd >>>>> rather get this over with, since we all know it probably ought >>>>> to >>>>> happen at some point in the future. >>>> >>>> Hi, >>>> there's a way to minimize the disruption on any outstanding >>>> forks, >>>> namely to automate the process. If we use the same "tool" on both >>>> main >>>> repo and the fork, the difference should be close to none. >>>> In this case something along the lines: >>>> >>>> find . -name "*.py" \ >>>> -exec sed -e "s/\([[:punct:]]\|[[:space:]]\)na\./\1np\./g" \ >>>> -e "s/numpy as na/numpy as np/g" -i {} \; >>>> >>>> should do the trick. I haven't check yet if that reproduces >>>> Anthony's >>>> PR >>>> so use it carefully ;) >>>> Cheers, >>>> Kacper >>>> >>>> >>>> >>>> _______________________________________________ >>>> yt-dev mailing list >>>> yt-dev@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (9)
-
Anthony Scopatz -
Britton Smith -
j s oishi -
John ZuHone -
Kacper Kowalik -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman -
Stephen Skory