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

Matthew Turk matthewturk at gmail.com
Mon Sep 10 11:14:58 PDT 2012 

Hi Sam,

On Mon, Sep 10, 2012 at 2:07 PM, Sam Skillman <samskillman at 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 at 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 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
>> _______________________________________________
>> 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