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

Sam Skillman samskillman at gmail.com
Mon Sep 10 11:07:16 PDT 2012 

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120910/a8c2d2b1/attachment.htm>

More information about the yt-dev mailing list