I think there remain some issues in the VR working in 3.0, which I
identified on the cookbook post on the trello board for yt-3.0. For
example, I know the overlaying grids and overlaying boundaries does not
currently work. That may be an easy fix, but it's something to keep in
mind. I was going to work on it last week as I was doing the cookbook
update, but I figured it was just going to get replaced with the scene
interface, so it wasn't worth the time.
I guess I'd still like to have all of the API breakage occur in the big
jump from 2.x to 3.0, but if people really want to get 3.0 out the door
asap, then perhaps that isn't compatible. Personally, I'm +1 on waiting to
have all the halo+VR stuff in 3.0 instead of 3.1, but if everyone else
wants a 3.0 out sooner, I will not block it. I think having a super fancy
VR and awesome halo interface is one of the big pulls to getting people who
have not yet switched to join 3.0 (from both 2.x as well as non-users) even
if it takes a few more months, but I may be the minority here.
Cameron
On Tue, Jun 24, 2014 at 10:08 AM, Nathan Goldbaum
Ok - I think the script in the issue description is sufficient. Let me know if you need something more detailed.
On Tue, Jun 24, 2014 at 10:07 AM, Matthew Turk
wrote: That's the one -- you mentioned it in a blockers email a few days ago.
On Tue, Jun 24, 2014 at 12:06 PM, Nathan Goldbaum
wrote: Sorry - not sure which issue you're talking about - this one maybe?
https://bitbucket.org/yt_analysis/yt/issue/827/enzo-particle-fields-work-dif...
On Tue, Jun 24, 2014 at 10:02 AM, Matthew Turk
wrote: Related to that, do you have a reproducible script for the particle issue you reported? If so, could you add that to either an issue or a trello card so I can work on it?
On Tue, Jun 24, 2014 at 11:58 AM, Nathan Goldbaum <
wrote:
I'd be +1 on this plan, although we should note that this is the
the release announcement. We may also want to note that there are some issues with volume rendering of oct and particle data at the moment (I believe that's the case - let me know if I'm wrong there).
I think that leaves analysis modules and documentation as the main blockers for a 3.0 release.
-Nathan
On Tue, Jun 24, 2014 at 9:53 AM, John ZuHone
wrote: +1 on Matt's proposal. -1 on a beta.
My worry about a beta release is that it will slow adoption, whether rightly or wrongly. I think we agree that we're ready to encourage adoption of 3.0.
John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com
> On Jun 24, 2014, at 12:38 PM, Matthew Turk
> wrote: > > I think Britton covered the halos, but the VR works as-is. As far as > 3.0beta, I'm a bit nervous about that as we want to avoid the > situation where we are in beta for 1+ years... I am worried about
> perception of a "beta" tag. Is that overblown? Would calling it > "yt-3.0-2014" work? > >> On Tue, Jun 24, 2014 at 10:32 AM, Nathan Goldbaum >>
wrote: >> Do the old VR and halo interfaces work? Not much effort has gone >> into >> porting them, I think. >> >> >>> On Tuesday, June 24, 2014, Sam Skillman >>> wrote: >>> >>> I'm +1 on this, particularly since I'm at fault for not pushing on >>> the >>> VR >>> as much as I'd like to. >>> >>> >>> On Tue, Jun 24, 2014 at 7:44 AM, Matthew Turk >>> >>> wrote: >>>> >>>> Hi all, >>>> >>>> One thing we really tried to do with 3.0 was break all the APIs we >>>> thought we'd need to before release. This included things like >>>> ds/pf, >>>> index/hierarchy, the way data selections were made, etc. >>>> >>>> It's starting to become clear that we are approaching maturity at >>>> different rates in these initiatives. I am wondering if >>>> we >>>> should de-couple the release from all of the API breakages, and >>>> instead note which interfaces we know are going to change in
>>>> future. >>>> >>>> Pragmatically, what this would mean is: >>>> >>>> * Release a 3.0 with the old VR and halo finding interfaces >>>> * Release a 3.1 with either the new VR or the new halo finding (or >>>> both) >>>> * Do the same for 3.2 >>>> >>>> This doesn't fit with the usual "major numbers are where APIs >>>> break" >>>> philosophy that comes from semantic versioning, but I think from >>>> the >>>> perspective of pragmatism, if we identify those sections of the >>>> code >>>> that are *going* to change, and we pitch 3.0 as the first part of >>>> a >>>> staged release of totally rewritten infrastructure, we can
nathan12343@gmail.com> plan in the perhaps the likely
>>>> come >>>> out okay. >>>> >>>> I'd like to put this out there for discussion. >>>> >>>> -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 _______________________________________________ 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
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org