[yt-dev] na => np in 3.0 and 2.x

Matthew Turk matthewturk at gmail.com
Mon Sep 10 10:55:43 PDT 2012 

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 at 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 at 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 at gmail.com> wrote:
>>> PR #258 sent.
>>>
>>>
>>> On Fri, Aug 31, 2012 at 10:31 AM, Anthony Scopatz <scopatz at gmail.com> wrote:
>>>>
>>>> On Fri, Aug 31, 2012 at 6:06 AM, Matthew Turk <matthewturk at 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 at 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 at 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 at 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 at lists.spacepope.org
>>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> yt-dev mailing list
>>>>>>> yt-dev at lists.spacepope.org
>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>>>
>>>>> _______________________________________________
>>>>> yt-dev mailing list
>>>>> yt-dev at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

More information about the yt-dev mailing list