[yt-svn] commit/yt: 4 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Sun Jul 24 09:19:44 PDT 2016
4 new commits in yt:
https://bitbucket.org/yt_analysis/yt/commits/5be60a71c30c/
Changeset: 5be60a71c30c
Branch: stable
User: ngoldbaum
Date: 2016-07-24 15:31:09+00:00
Summary: Merging work from yt branch into stable
Affected #: 995 files
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b .hgchurn
--- a/.hgchurn
+++ b/.hgchurn
@@ -1,6 +1,6 @@
stephenskory at yahoo.com = s at skory.us
"Stephen Skory stephenskory at yahoo.com" = s at skory.us
-yuan at astro.columbia.edu = bear0980 at gmail.com
+bear0980 at gmail.com = yuan at astro.columbia.edu
juxtaposicion at gmail.com = cemoody at ucsc.edu
chummels at gmail.com = chummels at astro.columbia.edu
jwise at astro.princeton.edu = jwise at physics.gatech.edu
@@ -19,7 +19,31 @@
sername=kayleanelson = kaylea.nelson at yale.edu
kayleanelson = kaylea.nelson at yale.edu
jcforbes at ucsc.edu = jforbes at ucolick.org
-ngoldbau at ucsc.edu = goldbaum at ucolick.org
biondo at wisc.edu = Biondo at wisc.edu
samgeen at googlemail.com = samgeen at gmail.com
-fbogert = fbogert at ucsc.edu
\ No newline at end of file
+fbogert = fbogert at ucsc.edu
+bwoshea = oshea at msu.edu
+mornkr at slac.stanford.edu = me at jihoonkim.org
+kbarrow = kssbarrow at gatech.edu
+kssbarrow at gmail.com = kssbarrow at gatech.edu
+kassbarrow at gmail.com = kssbarrow at gatech.edu
+antoine.strugarek at cea.fr = strugarek at astro.umontreal.ca
+rosen at ucolick.org = alrosen at ucsc.edu
+jzuhone = jzuhone at gmail.com
+karraki at nmsu.edu = karraki at gmail.com
+hckr at eml.cc = astrohckr at gmail.com
+julian3 at illinois.edu = astrohckr at gmail.com
+cosmosquark = bthompson2090 at gmail.com
+chris.m.malone at lanl.gov = chris.m.malone at gmail.com
+jnaiman at ucolick.org = jnaiman
+migueld.deval = miguel at archlinux.net
+slevy at ncsa.illinois.edu = salevy at illinois.edu
+malzraa at gmail.com = kellerbw at mcmaster.ca
+None = convert-repo
+dfenn = df11c at my.fsu.edu
+langmm = langmm.astro at gmail.com
+jmt354 = jmtomlinson95 at gmail.com
+desika = dnarayan at haverford.edu
+Ben Thompson = bthompson2090 at gmail.com
+goldbaum at ucolick.org = ngoldbau at illinois.edu
+ngoldbau at ucsc.edu = ngoldbau at illinois.edu
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b .hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -10,6 +10,7 @@
yt/analysis_modules/halo_finding/rockstar/rockstar_groupies.c
yt/analysis_modules/halo_finding/rockstar/rockstar_interface.c
yt/analysis_modules/ppv_cube/ppv_utils.c
+yt/analysis_modules/photon_simulator/utils.c
yt/frontends/ramses/_ramses_reader.cpp
yt/frontends/sph/smoothing_kernel.c
yt/geometry/fake_octree.c
@@ -27,35 +28,51 @@
yt/utilities/spatial/ckdtree.c
yt/utilities/lib/alt_ray_tracers.c
yt/utilities/lib/amr_kdtools.c
+yt/utilities/lib/basic_octree.c
yt/utilities/lib/bitarray.c
-yt/utilities/lib/CICDeposit.c
-yt/utilities/lib/ContourFinding.c
-yt/utilities/lib/DepthFirstOctree.c
-yt/utilities/lib/FixedInterpolator.c
+yt/utilities/lib/bounding_volume_hierarchy.c
+yt/utilities/lib/contour_finding.c
+yt/utilities/lib/depth_first_octree.c
+yt/utilities/lib/element_mappings.c
yt/utilities/lib/fortran_reader.c
yt/utilities/lib/freetype_writer.c
yt/utilities/lib/geometry_utils.c
+yt/utilities/lib/image_samplers.c
yt/utilities/lib/image_utilities.c
-yt/utilities/lib/Interpolators.c
+yt/utilities/lib/interpolators.c
yt/utilities/lib/kdtree.c
+yt/utilities/lib/lenses.c
+yt/utilities/lib/line_integral_convolution.c
+yt/utilities/lib/mesh_construction.cpp
+yt/utilities/lib/mesh_intersection.cpp
+yt/utilities/lib/mesh_samplers.cpp
+yt/utilities/lib/mesh_traversal.cpp
+yt/utilities/lib/mesh_triangulation.c
yt/utilities/lib/mesh_utilities.c
yt/utilities/lib/misc_utilities.c
-yt/utilities/lib/Octree.c
-yt/utilities/lib/GridTree.c
+yt/utilities/lib/particle_mesh_operations.c
+yt/utilities/lib/partitioned_grid.c
+yt/utilities/lib/primitives.c
yt/utilities/lib/origami.c
+yt/utilities/lib/particle_mesh_operations.c
yt/utilities/lib/pixelization_routines.c
yt/utilities/lib/png_writer.c
-yt/utilities/lib/PointsInVolume.c
-yt/utilities/lib/QuadTree.c
-yt/utilities/lib/RayIntegrators.c
+yt/utilities/lib/points_in_volume.c
+yt/utilities/lib/quad_tree.c
+yt/utilities/lib/ray_integrators.c
yt/utilities/lib/ragged_arrays.c
-yt/utilities/lib/VolumeIntegrator.c
yt/utilities/lib/grid_traversal.c
yt/utilities/lib/marching_cubes.c
yt/utilities/lib/png_writer.h
yt/utilities/lib/write_array.c
+yt/utilities/lib/perftools_wrap.c
+yt/utilities/lib/partitioned_grid.c
+yt/utilities/lib/volume_container.c
+yt/utilities/lib/lenses.c
+yt/utilities/lib/image_samplers.c
syntax: glob
*.pyc
+*.pyd
.*.swp
*.so
.idea/*
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b CONTRIBUTING.rst
--- /dev/null
+++ b/CONTRIBUTING.rst
@@ -0,0 +1,970 @@
+.. This document is rendered in HTML with cross-reference links filled in at
+ http://yt-project.org/doc/developing/
+
+.. _getting-involved:
+
+Getting Involved
+================
+
+There are *lots* of ways to get involved with yt, as a community and as a
+technical system -- not all of them just contributing code, but also
+participating in the community, helping us with designing the websites, adding
+documentation, and sharing your scripts with others.
+
+Coding is only one way to be involved!
+
+Communication Channels
+----------------------
+
+There are five main communication channels for yt:
+
+ * We have an IRC channel, on ``irc.freenode.net`` in ``#yt``.
+ You can connect through our web
+ gateway without any special client, at http://yt-project.org/irc.html .
+ *IRC is the first stop for conversation!*
+ * Many yt developers participate in the yt Slack community. Slack is a free
+ chat service that many teams use to organize their work. You can get an
+ invite to yt's Slack organization by clicking the "Join us @ Slack" button
+ on this page: http://yt-project.org/community.html
+ * `yt-users <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>`_
+ is a relatively high-traffic mailing list where people are encouraged to ask
+ questions about the code, figure things out and so on.
+ * `yt-dev <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_ is
+ a much lower-traffic mailing list designed to focus on discussions of
+ improvements to the code, ideas about planning, development issues, and so
+ on.
+ * `yt-svn <http://lists.spacepope.org/listinfo.cgi/yt-svn-spacepope.org>`_ is
+ the (now-inaccurately titled) mailing list where all pushes to the primary
+ repository are sent.
+
+The easiest way to get involved with yt is to read the mailing lists, hang out
+in IRC or slack chat, and participate. If someone asks a question you know the
+answer to (or have your own question about!) write back and answer it.
+
+If you have an idea about something, suggest it! We not only welcome
+participation, we encourage it.
+
+Documentation
+-------------
+
+The yt documentation is constantly being updated, and it is a task we would very
+much appreciate assistance with. Whether that is adding a section, updating an
+outdated section, contributing typo or grammatical fixes, adding a FAQ, or
+increasing coverage of functionality, it would be very helpful if you wanted to
+help out.
+
+The easiest way to help out is to fork the main yt repository (where the
+documentation lives in the ``doc`` directory in the root of the yt mercurial
+repository) and then make your changes in your own fork. When you are done,
+issue a pull request through the website for your new fork, and we can comment
+back and forth and eventually accept your changes. See :ref:`sharing-changes` for
+more information about contributing your changes to yt on bitbucket.
+
+Gallery Images and Videos
+-------------------------
+
+If you have an image or video you'd like to display in the image or video
+galleries, getting it included it easy! You can either fork the `yt homepage
+repository <http://bitbucket.org/yt_analysis/website>`_ and add it there, or
+email it to us and we'll add it to the `Gallery
+<http://yt-project.org/gallery.html>`_.
+
+We're eager to show off the images and movies you make with yt, so please feel
+free to drop `us <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_
+a line and let us know if you've got something great!
+
+Technical Contributions
+-----------------------
+
+Contributing code is another excellent way to participate -- whether it's
+bug fixes, new features, analysis modules, or a new code frontend. See
+:ref:`creating_frontend` for more details.
+
+The process is pretty simple: fork on BitBucket, make changes, issue a pull
+request. We can then go back and forth with comments in the pull request, but
+usually we end up accepting.
+
+For more information, see :ref:`contributing-code`, where we spell out how to
+get up and running with a development environment, how to commit, and how to
+use BitBucket.
+
+Online Presence
+---------------
+
+Some of these fall under the other items, but if you'd like to help out with
+the website or any of the other ways yt is presented online, please feel free!
+Almost everything is kept in hg repositories on BitBucket, and it is very easy
+to fork and contribute back changes.
+
+Please feel free to dig in and contribute changes.
+
+Word of Mouth
+-------------
+
+If you're using yt and it has increased your productivity, please feel
+encouraged to share that information. Cite our `paper
+<http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_, tell your colleagues,
+and just spread word of mouth. By telling people about your successes, you'll
+help bring more eyes and hands to the table -- in this manner, by increasing
+participation, collaboration, and simply spreading the limits of what the code
+is asked to do, we hope to help scale the utility and capability of yt with the
+community size.
+
+Feel free to `blog <http://blog.yt-project.org/>`_ about, `tweet
+<http://twitter.com/yt_astro>`_ about and talk about what you are up to!
+
+Long-Term Projects
+------------------
+
+There are some wild-eyed, out-there ideas that have been bandied about for the
+future directions of yt -- some of them even written into the mission
+statement. The ultimate goal is to move past simple analysis and visualization
+of data and begin to approach it from the other side, of generating data,
+running solvers. We also hope to increase its ability to act as an in situ
+analysis code, by presenting a unified protocol. Other projects include
+interfacing with ParaView and VisIt, creating a web GUI for running
+simulations, creating a run-tracker that follows simulations in progress, a
+federated database for simulation outputs, and so on and so forth.
+
+yt is an ambitious project. Let's be ambitious together.
+
+yt Community Code of Conduct
+----------------------------
+
+The community of participants in open source
+Scientific projects is made up of members from around the
+globe with a diverse set of skills, personalities, and
+experiences. It is through these differences that our
+community experiences success and continued growth. We
+expect everyone in our community to follow these guidelines
+when interacting with others both inside and outside of our
+community. Our goal is to keep ours a positive, inclusive,
+successful, and growing community.
+
+As members of the community,
+
+- We pledge to treat all people with respect and
+ provide a harassment- and bullying-free environment,
+ regardless of sex, sexual orientation and/or gender
+ identity, disability, physical appearance, body size,
+ race, nationality, ethnicity, and religion. In
+ particular, sexual language and imagery, sexist,
+ racist, or otherwise exclusionary jokes are not
+ appropriate.
+
+- We pledge to respect the work of others by
+ recognizing acknowledgment/citation requests of
+ original authors. As authors, we pledge to be explicit
+ about how we want our own work to be cited or
+ acknowledged.
+
+- We pledge to welcome those interested in joining the
+ community, and realize that including people with a
+ variety of opinions and backgrounds will only serve to
+ enrich our community. In particular, discussions
+ relating to pros/cons of various technologies,
+ programming languages, and so on are welcome, but
+ these should be done with respect, taking proactive
+ measure to ensure that all participants are heard and
+ feel confident that they can freely express their
+ opinions.
+
+- We pledge to welcome questions and answer them
+ respectfully, paying particular attention to those new
+ to the community. We pledge to provide respectful
+ criticisms and feedback in forums, especially in
+ discussion threads resulting from code
+ contributions.
+
+- We pledge to be conscientious of the perceptions of
+ the wider community and to respond to criticism
+ respectfully. We will strive to model behaviors that
+ encourage productive debate and disagreement, both
+ within our community and where we are criticized. We
+ will treat those outside our community with the same
+ respect as people within our community.
+
+- We pledge to help the entire community follow the
+ code of conduct, and to not remain silent when we see
+ violations of the code of conduct. We will take action
+ when members of our community violate this code such as
+ contacting confidential at yt-project.org (all emails sent to
+ this address will be treated with the strictest
+ confidence) or talking privately with the person.
+
+This code of conduct applies to all
+community situations online and offline, including mailing
+lists, forums, social media, conferences, meetings,
+associated social events, and one-to-one interactions.
+
+The yt Community Code of Conduct was adapted from the
+`Astropy Community Code of Conduct
+<http://www.astropy.org/about.html#codeofconduct>`_,
+which was partially inspired by the PSF code of conduct.
+
+.. _contributing-code:
+
+How to Develop yt
+=================
+
+yt is a community project!
+
+We are very happy to accept patches, features, and bugfixes from any member of
+the community! yt is developed using mercurial, primarily because it enables
+very easy and straightforward submission of changesets. We're eager to hear
+from you, and if you are developing yt, we encourage you to subscribe to the
+`developer mailing list
+<http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_. Please feel
+free to hack around, commit changes, and send them upstream.
+
+.. note:: If you already know how to use the `mercurial version control system
+ <http://mercurial-scm.org>`_ and are comfortable with handling it yourself,
+ the quickest way to contribute to yt is to `fork us on BitBucket
+ <http://bitbucket.org/yt_analysis/yt/fork>`_, make your changes, push the
+ changes to your fork and issue a `pull request
+ <http://bitbucket.org/yt_analysis/yt/pull-requests>`_. The rest of this
+ document is just an explanation of how to do that.
+
+See :ref:`code-style-guide` for more information about coding style in yt and
+:ref:`docstrings` for an example docstring. Please read them before hacking on
+the codebase, and feel free to email any of the mailing lists for help with the
+codebase.
+
+Keep in touch, and happy hacking!
+
+.. _open-issues:
+
+Open Issues
+-----------
+
+If you're interested in participating in yt development, take a look at the
+`issue tracker on bitbucket
+<https://bitbucket.org/yt_analysis/yt/issues?milestone=easy?status=new>`_.
+Issues are marked with a milestone of "easy", "moderate", or "difficult"
+depending on the estimated level of difficulty for fixing the issue. While we
+try to triage the issue tracker regularly, it may be the case that issues marked
+"moderate" are actually easier than their milestone label indicates since that
+is the default value.
+
+Here are some predefined issue searches that might be useful:
+
+* Unresolved issues `marked "easy" <https://bitbucket.org/yt_analysis/yt/issues?milestone=easy&status=open&status=new>`_.
+* Unresolved issues `marked "easy" or "moderate" <https://bitbucket.org/yt_analysis/yt/issues?milestone=easy&milestone=moderate&status=open&status=new>`_
+* `All unresolved issues <https://bitbucket.org/yt_analysis/yt/issues?status=open&status=new>`_
+
+Submitting Changes
+------------------
+
+We provide a brief introduction to submitting changes here. yt thrives on the
+strength of its communities (http://arxiv.org/abs/1301.7064 has further
+discussion) and we encourage contributions from any user. While we do not
+discuss version control, mercurial or the advanced usage of BitBucket in detail
+here, we do provide an outline of how to submit changes and we are happy to
+provide further assistance or guidance.
+
+Licensing
++++++++++
+
+yt is `licensed <http://blog.yt-project.org/post/Relicensing.html>`_ under the
+BSD 3-clause license. Versions previous to yt-2.6 were released under the GPLv3.
+
+All contributed code must be BSD-compatible. If you'd rather not license in
+this manner, but still want to contribute, please consider creating an external
+package, which we'll happily link to.
+
+How To Get The Source Code For Editing
+++++++++++++++++++++++++++++++++++++++
+
+yt is hosted on BitBucket, and you can see all of the yt repositories at
+http://bitbucket.org/yt_analysis/. With the yt installation script you should have a
+copy of Mercurial for checking out pieces of code. Make sure you have followed
+the steps above for bootstrapping your development (to assure you have a
+bitbucket account, etc.)
+
+In order to modify the source code for yt, we ask that you make a "fork" of the
+main yt repository on bitbucket. A fork is simply an exact copy of the main
+repository (along with its history) that you will now own and can make
+modifications as you please. You can create a personal fork by visiting the yt
+bitbucket webpage at https://bitbucket.org/yt_analysis/yt/ . After logging in,
+you should see an option near the top right labeled "fork". Click this option,
+and then click the fork repository button on the subsequent page. You now have
+a forked copy of the yt repository for your own personal modification.
+
+This forked copy exists on the bitbucket repository, so in order to access
+it locally, follow the instructions at the top of that webpage for that
+forked repository, namely run at a local command line:
+
+.. code-block:: bash
+
+ $ hg clone http://bitbucket.org/<USER>/<REPOSITORY_NAME>
+
+This downloads that new forked repository to your local machine, so that you
+can access it, read it, make modifications, etc. It will put the repository in
+a local directory of the same name as the repository in the current working
+directory. You can see any past state of the code by using the hg log command.
+For example, the following command would show you the last 5 changesets
+(modifications to the code) that were submitted to that repository.
+
+.. code-block:: bash
+
+ $ cd <REPOSITORY_NAME>
+ $ hg log -l 5
+
+Using the revision specifier (the number or hash identifier next to each
+changeset), you can update the local repository to any past state of the
+code (a previous changeset or version) by executing the command:
+
+.. code-block:: bash
+
+ $ hg up revision_specifier
+
+Lastly, if you want to use this new downloaded version of your yt repository as
+the *active* version of yt on your computer (i.e. the one which is executed when
+you run yt from the command line or the one that is loaded when you do ``import
+yt``), then you must "activate" it using the following commands from within the
+repository directory.
+
+.. code-block:: bash
+
+ $ cd <REPOSITORY_NAME>
+ $ python2.7 setup.py develop
+
+This will rebuild all C modules as well.
+
+.. _reading-source:
+
+How To Read The Source Code
++++++++++++++++++++++++++++
+
+If you just want to *look* at the source code, you may already have it on your
+computer. If you build yt using the install script, the source is available at
+``$YT_DEST/src/yt-hg``. See :ref:`source-installation` for more details about
+to obtain the yt source code if you did not build yt using the install
+script.
+
+The root directory of the yt mercurial repository contains a number of
+subdirectories with different components of the code. Most of the yt source
+code is contained in the yt subdirectory. This directory its self contains
+the following subdirectories:
+
+``frontends``
+ This is where interfaces to codes are created. Within each subdirectory of
+ yt/frontends/ there must exist the following files, even if empty:
+
+ * ``data_structures.py``, where subclasses of AMRGridPatch, Dataset
+ and AMRHierarchy are defined.
+ * ``io.py``, where a subclass of IOHandler is defined.
+ * ``fields.py``, where fields we expect to find in datasets are defined
+ * ``misc.py``, where any miscellaneous functions or classes are defined.
+ * ``definitions.py``, where any definitions specific to the frontend are
+ defined. (i.e., header formats, etc.)
+
+``fields``
+ This is where all of the derived fields that ship with yt are defined.
+
+``geometry``
+ This is where geometric helpler routines are defined. Handlers
+ for grid and oct data, as well as helpers for coordinate transformations
+ can be found here.
+
+``visualization``
+ This is where all visualization modules are stored. This includes plot
+ collections, the volume rendering interface, and pixelization frontends.
+
+``data_objects``
+ All objects that handle data, processed or unprocessed, not explicitly
+ defined as visualization are located in here. This includes the base
+ classes for data regions, covering grids, time series, and so on. This
+ also includes derived fields and derived quantities.
+
+``analysis_modules``
+ This is where all mechanisms for processing data live. This includes
+ things like clump finding, halo profiling, halo finding, and so on. This
+ is something of a catchall, but it serves as a level of greater
+ abstraction that simply data selection and modification.
+
+``gui``
+ This is where all GUI components go. Typically this will be some small
+ tool used for one or two things, which contains a launching mechanism on
+ the command line.
+
+``utilities``
+ All broadly useful code that doesn't clearly fit in one of the other
+ categories goes here.
+
+``extern``
+ Bundled external modules (i.e. code that was not written by one of
+ the yt authors but that yt depends on) lives here.
+
+
+If you're looking for a specific file or function in the yt source code, use
+the unix find command:
+
+.. code-block:: bash
+
+ $ find <DIRECTORY_TREE_TO_SEARCH> -name '<FILENAME>'
+
+The above command will find the FILENAME in any subdirectory in the
+DIRECTORY_TREE_TO_SEARCH. Alternatively, if you're looking for a function
+call or a keyword in an unknown file in a directory tree, try:
+
+.. code-block:: bash
+
+ $ grep -R <KEYWORD_TO_FIND><DIRECTORY_TREE_TO_SEARCH>
+
+This can be very useful for tracking down functions in the yt source.
+
+.. _building-yt:
+
+Building yt
++++++++++++
+
+If you have made changes to any C or Cython (``.pyx``) modules, you have to
+rebuild yt. If your changes have exclusively been to Python modules, you will
+not need to re-build, but (see below) you may need to re-install.
+
+If you are running from a clone that is executable in-place (i.e., has been
+installed via the installation script or you have run ``setup.py develop``) you
+can rebuild these modules by executing:
+
+.. code-block:: bash
+
+ $ python2.7 setup.py develop
+
+If you have previously "installed" via ``setup.py install`` you have to
+re-install:
+
+.. code-block:: bash
+
+ $ python2.7 setup.py install
+
+Only one of these two options is needed.
+
+.. _windows-developing:
+
+Developing yt on Windows
+------------------------
+
+If you plan to develop yt on Windows, it is necessary to use the `MinGW
+<http://www.mingw.org/>`_ gcc compiler that can be installed using the `Anaconda
+Python Distribution <https://store.continuum.io/cshop/anaconda/>`_. The libpython package must be
+installed from Anaconda as well. These can both be installed with a single command:
+
+.. code-block:: bash
+
+ $ conda install libpython mingw
+
+Additionally, the syntax for the setup command is slightly different; you must type:
+
+.. code-block:: bash
+
+ $ python2.7 setup.py build --compiler=mingw32 develop
+
+or
+
+.. code-block:: bash
+
+ $ python2.7 setup.py build --compiler=mingw32 install
+
+.. _requirements-for-code-submission:
+
+Requirements for Code Submission
+--------------------------------
+
+Modifications to the code typically fall into one of three categories, each of
+which have different requirements for acceptance into the code base. These
+requirements are in place for a few reasons -- to make sure that the code is
+maintainable, testable, and that we can easily include information about
+changes in changelogs during the release procedure. (See `YTEP-0008
+<https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0008.html>`_ for more
+detail.)
+
+* New Features
+
+ * New unit tests (possibly new answer tests) (See :ref:`testing`)
+ * Docstrings in the source code for the public API
+ * Addition of new feature to the narrative documentation (See :ref:`writing_documentation`)
+ * Addition of cookbook recipe (See :ref:`writing_documentation`)
+ * Issue created on issue tracker, to ensure this is added to the changelog
+
+* Extension or Breakage of API in Existing Features
+
+ * Update existing narrative docs and docstrings (See :ref:`writing_documentation`)
+ * Update existing cookbook recipes (See :ref:`writing_documentation`)
+ * Modify of create new unit tests (See :ref:`testing`)
+ * Issue created on issue tracker, to ensure this is added to the changelog
+
+* Bug fixes
+
+ * Unit test is encouraged, to ensure breakage does not happen again in the
+ future. (See :ref:`testing`)
+ * Issue created on issue tracker, to ensure this is added to the changelog
+
+When submitting, you will be asked to make sure that your changes meet all of
+these requirements. They are pretty easy to meet, and we're also happy to help
+out with them. In :ref:`code-style-guide` there is a list of handy tips for
+how to structure and write your code.
+
+.. _mercurial-with-yt:
+
+How to Use Mercurial with yt
+----------------------------
+
+If you're new to Mercurial, these three resources are pretty great for learning
+the ins and outs:
+
+* http://hginit.com/
+* http://hgbook.red-bean.com/read/
+* http://mercurial-scm.org/
+* http://mercurial-scm.org/wiki
+
+The commands that are essential for using mercurial include:
+
+* ``hg help`` which provides help for any mercurial command. For example, you
+ can learn more about the ``log`` command by doing ``hg help log``. Other useful
+ topics to use with ``hg help`` are ``hg help glossary``, ``hg help config``,
+ ``hg help extensions``, and ``hg help revsets``.
+* ``hg commit`` which commits changes in the working directory to the
+ repository, creating a new "changeset object."
+* ``hg add`` which adds a new file to be tracked by mercurial. This does
+ not change the working directory.
+* ``hg pull`` which pulls (from an optional path specifier) changeset
+ objects from a remote source. The working directory is not modified.
+* ``hg push`` which sends (to an optional path specifier) changeset objects
+ to a remote source. The working directory is not modified.
+* ``hg log`` which shows a log of all changeset objects in the current
+ repository. Use ``-G`` to show a graph of changeset objects and their
+ relationship.
+* ``hg update`` which (with an optional "revision" specifier) updates the
+ state of the working directory to match a changeset object in the
+ repository.
+* ``hg merge`` which combines two changesets to make a union of their lines
+ of development. This updates the working directory.
+
+We are happy to asnswers questions about mercurial use on our IRC, slack
+chat or on the mailing list to walk you through any troubles you might have.
+Here are some general suggestions for using mercurial with yt:
+
+* Named branches are to be avoided. Try using bookmarks (``see hg help
+ bookmark``) to track work. (`More info about bookmarks is available on the
+ mercurial wiki <http://mercurial-scm.org/wiki/Bookmarks>`_)
+* Make sure you set a username in your ``~/.hgrc`` before you commit any
+ changes! All of the tutorials above will describe how to do this as one of
+ the very first steps.
+* When contributing changes, you might be asked to make a handful of
+ modifications to your source code. We'll work through how to do this with
+ you, and try to make it as painless as possible.
+* Your test may fail automated style checks. See :ref:`code-style-guide` for
+ more information about automatically verifying your code style.
+* Please avoid deleting your yt forks, as that deletes the pull request
+ discussion from process from BitBucket's website, even if your pull request
+ is merged.
+* You should only need one fork. To keep it in sync, you can sync from the
+ website. See Bitbucket's `Blog Post
+ <https://blog.bitbucket.org/2013/02/04/syncing-and-merging-come-to-bitbucket/>`_
+ about this. See :ref:`sharing-changes` for a description of the basic workflow
+ and :ref:`multiple-PRs` for a discussion about what to do when you want to
+ have multiple open pull requests at the same time.
+* If you run into any troubles, stop by IRC (see :ref:`irc`) or the mailing
+ list.
+
+.. _sharing-changes:
+
+Making and Sharing Changes
+--------------------------
+
+The simplest way to submit changes to yt is to do the following:
+
+* Build yt from the mercurial repository
+* Navigate to the root of the yt repository
+* Make some changes and commit them
+* Fork the `yt repository on BitBucket <https://bitbucket.org/yt_analysis/yt>`_
+* Push the changesets to your fork
+* Issue a pull request.
+
+Here's a more detailed flowchart of how to submit changes.
+
+#. If you have used the installation script, the source code for yt can be
+ found in ``$YT_DEST/src/yt-hg``. Alternatively see
+ :ref:`source-installation` for instructions on how to build yt from the
+ mercurial repository. (Below, in :ref:`reading-source`, we describe how to
+ find items of interest.)
+#. Edit the source file you are interested in and
+ test your changes. (See :ref:`testing` for more information.)
+#. Fork yt on BitBucket. (This step only has to be done once.) You can do
+ this at: https://bitbucket.org/yt_analysis/yt/fork. Call this repository
+ yt.
+#. Create a bookmark to track your work. For example: ``hg bookmark
+ my-first-pull-request``
+#. Commit these changes, using ``hg commit``. This can take an argument
+ which is a series of filenames, if you have some changes you do not want
+ to commit.
+#. Remember that this is a large development effort and to keep the code
+ accessible to everyone, good documentation is a must. Add in source code
+ comments for what you are doing. Add in docstrings
+ if you are adding a new function or class or keyword to a function.
+ Add documentation to the appropriate section of the online docs so that
+ people other than yourself know how to use your new code.
+#. If your changes include new functionality or cover an untested area of the
+ code, add a test. (See :ref:`testing` for more information.) Commit
+ these changes as well.
+#. Push your changes to your new fork using the command::
+
+ hg push -B my-first-pull-request https://bitbucket.org/YourUsername/yt/
+
+ Where you should substitute the name of the bookmark you are working on for
+ ``my-first-pull-request``. If you end up doing considerable development, you
+ can set an alias in the file ``.hg/hgrc`` to point to this path.
+
+ .. note::
+ Note that the above approach uses HTTPS as the transfer protocol
+ between your machine and BitBucket. If you prefer to use SSH - or
+ perhaps you're behind a proxy that doesn't play well with SSL via
+ HTTPS - you may want to set up an `SSH key`_ on BitBucket. Then, you use
+ the syntax ``ssh://hg@bitbucket.org/YourUsername/yt``, or equivalent, in
+ place of ``https://bitbucket.org/YourUsername/yt`` in Mercurial commands.
+ For consistency, all commands we list in this document will use the HTTPS
+ protocol.
+
+ .. _SSH key: https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Mercurial
+
+#. Issue a pull request at
+ https://bitbucket.org/YourUsername/yt/pull-request/new
+ A pull request is essentially just asking people to review and accept the
+ modifications you have made to your personal version of the code.
+
+
+During the course of your pull request you may be asked to make changes. These
+changes may be related to style issues, correctness issues, or even requesting
+tests. The process for responding to pull request code review is relatively
+straightforward.
+
+#. Make requested changes, or leave a comment indicating why you don't think
+ they should be made.
+#. Commit those changes to your local repository.
+#. Push the changes to your fork:
+
+ hg push https://bitbucket.org/YourUsername/yt/
+
+#. Your pull request will be automatically updated.
+
+.. _multiple-PRs:
+
+Working with Multiple BitBucket Pull Requests
+---------------------------------------------
+
+Once you become active developing for yt, you may be working on
+various aspects of the code or bugfixes at the same time. Currently,
+BitBucket's *modus operandi* for pull requests automatically updates
+your active pull request with every ``hg push`` of commits that are a
+descendant of the head of your pull request. In a normal workflow,
+this means that if you have an active pull request, make some changes
+locally for, say, an unrelated bugfix, then push those changes back to
+your fork in the hopes of creating a *new* pull request, you'll
+actually end up updating your current pull request!
+
+There are a few ways around this feature of BitBucket that will allow
+for multiple pull requests to coexist; we outline one such method
+below. We assume that you have a fork of yt at
+``http://bitbucket.org/YourUsername/Your_yt`` (see
+:ref:`sharing-changes` for instructions on creating a fork) and that
+you have an active pull request to the main repository.
+
+The main issue with starting another pull request is to make sure that
+your push to BitBucket doesn't go to the same head as your
+existing pull request and trigger BitBucket's auto-update feature.
+Here's how to get your local repository away from your current pull
+request head using `revsets <http://www.selenic.com/hg/help/revsets>`_
+and your ``hgrc`` file:
+
+#. Set up a Mercurial path for the main yt repository (note this is a convenience
+ step and only needs to be done once). Add the following to your
+ ``Your_yt/.hg/hgrc``::
+
+ [paths]
+ upstream = https://bitbucket.org/yt_analysis/yt
+
+ This will create a path called ``upstream`` that is aliased to the URL of the
+ main yt repository.
+#. Now we'll use revsets_ to update your local repository to the tip of the
+ ``upstream`` path:
+
+ .. code-block:: bash
+
+ $ hg pull upstream
+ $ hg update -r "remote(yt, 'upstream')"
+
+After the above steps, your local repository should be at the current head of
+the ``yt`` branch in the main yt repository. If you find yourself doing this a
+lot, it may be worth aliasing this task in your ``hgrc`` file by adding
+something like::
+
+ [alias]
+ ytupdate = update -r "remote(yt, 'upstream')"
+
+And then you can just issue ``hg ytupdate`` to get at the current head of the
+``yt`` branch on main yt repository.
+
+Make sure you are on the branch you want to be on, and then you can make changes
+and ``hg commit`` them. If you prefer working with `bookmarks
+<http://mercurial-scm.org/wiki/Bookmarks>`_, you may want to make a bookmark
+before committing your changes, such as ``hg bookmark mybookmark``.
+
+To push your changes on a bookmark to bitbucket, you can issue the following
+command:
+
+.. code-block:: bash
+
+ $ hg push -B myfeature https://bitbucket.org/YourUsername/Your_yt
+
+The ``-B`` means "publish my bookmark, the changeset the bookmark is pointing
+at, and any ancestors of that changeset that aren't already on the remote
+server".
+
+To push to your fork on BitBucket if you didn't use a bookmark, you issue the
+following:
+
+.. code-block:: bash
+
+ $ hg push -r . -f https://bitbucket.org/YourUsername/Your_yt
+
+The ``-r .`` means "push only the commit I'm standing on and any ancestors."
+The ``-f`` is to force Mecurial to do the push since we are creating a new
+remote head without a bookmark.
+
+You can then go to the BitBucket interface and issue a new pull request based on
+your last changes, as usual.
+
+.. _code-style-guide:
+
+Coding Style Guide
+==================
+
+Automatically checking code style
+---------------------------------
+
+Below are a list of rules for coding style in yt. Some of these rules are
+suggestions are not explicitly enforced, while some are enforced via automated
+testing. The yt project uses a subset of the rules checked by ``flake8`` to
+verify our code. The ``flake8`` tool is a combination of the ``pyflakes`` and
+``pep8`` tools. To check the coding style of your contributions locally you will
+need to install the ``flake8`` tool from ``pip``:
+
+.. code-block:: bash
+
+ $ pip install flake8
+
+And then navigate to the root of the yt repository and run ``flake8`` on the
+``yt`` folder:
+
+.. code-block:: bash
+
+ $ cd $YT_HG
+ $ flake8 ./yt
+
+This will print out any ``flake8`` errors or warnings that your newly added code
+triggers. The errors will be in your newly added code because we have already
+cleaned up the rest of the yt codebase of the errors and warnings detected by
+the `flake8` tool. Note that this will only trigger a subset of the `full flake8
+error and warning list
+<http://flake8.readthedocs.org/en/latest/warnings.html>`_, since we explicitly
+blacklist a large number of the full list of rules that are checked by
+``flake8`` by default.
+
+Source code style guide
+-----------------------
+
+ * In general, follow PEP-8 guidelines.
+ http://www.python.org/dev/peps/pep-0008/
+ * Classes are ``ConjoinedCapitals``, methods and functions are
+ ``lowercase_with_underscores``.
+ * Use 4 spaces, not tabs, to represent indentation.
+ * Line widths should not be more than 80 characters.
+ * Do not use nested classes unless you have a very good reason to, such as
+ requiring a namespace or class-definition modification. Classes should live
+ at the top level. ``__metaclass__`` is exempt from this.
+ * Do not use unnecessary parenthesis in conditionals. ``if((something) and
+ (something_else))`` should be rewritten as
+ ``if something and something_else``. Python is more forgiving than C.
+ * Avoid copying memory when possible. For example, don't do
+ ``a = a.reshape(3,4)`` when ``a.shape = (3,4)`` will do, and ``a = a * 3``
+ should be ``np.multiply(a, 3, a)``.
+ * In general, avoid all double-underscore method names: ``__something`` is
+ usually unnecessary.
+ * When writing a subclass, use the super built-in to access the super class,
+ rather than explicitly. Ex: ``super(SpecialGridSubclass, self).__init__()``
+ rather than ``SpecialGrid.__init__()``.
+ * Docstrings should describe input, output, behavior, and any state changes
+ that occur on an object. See :ref:`docstrings` below for a fiducial example
+ of a docstring.
+ * Use only one top-level import per line. Unless there is a good reason not to,
+ imports should happen at the top of the file, after the copyright blurb.
+ * Never compare with ``True`` or ``False`` using ``==`` or ``!=``, always use
+ ``is`` or ``is not``.
+ * If you are comparing with a numpy boolean array, just refer to the array.
+ Ex: do ``np.all(array)`` instead of ``np.all(array == True)``.
+ * Never comapre with None using ``==`` or ``!=``, use ``is None`` or
+ ``is not None``.
+ * Use ``statement is not True`` instead of ``not statement is True``
+ * Only one statement per line, do not use semicolons to put two or more
+ statements on a single line.
+ * Only declare local variables if they will be used later. If you do not use the
+ return value of a function, do not store it in a variable.
+ * Add tests for new functionality. When fixing a bug, consider adding a test to
+ prevent the bug from recurring.
+
+API Style Guide
+---------------
+
+ * Do not use ``from some_module import *``
+ * Internally, only import from source files directly -- instead of:
+
+ ``from yt.visualization.api import ProjectionPlot``
+
+ do:
+
+ ``from yt.visualization.plot_window import ProjectionPlot``
+
+ * Import symbols from the module where they are defined, avoid transitive
+ imports.
+ * Import standard library modules, functions, and classes from builtins, do not
+ import them from other yt files.
+ * Numpy is to be imported as ``np``.
+ * Do not use too many keyword arguments. If you have a lot of keyword
+ arguments, then you are doing too much in ``__init__`` and not enough via
+ parameter setting.
+ * In function arguments, place spaces before commas. ``def something(a,b,c)``
+ should be ``def something(a, b, c)``.
+ * Don't create a new class to replicate the functionality of an old class --
+ replace the old class. Too many options makes for a confusing user
+ experience.
+ * Parameter files external to yt are a last resort.
+ * The usage of the ``**kwargs`` construction should be avoided. If they cannot
+ be avoided, they must be explained, even if they are only to be passed on to
+ a nested function.
+
+.. _docstrings:
+
+Docstrings
+----------
+
+The following is an example docstring. You can use it as a template for
+docstrings in your code and as a guide for how we expect docstrings to look and
+the level of detail we are looking for. Note that we use NumPy style docstrings
+written in `Sphinx restructured text format <http://sphinx-doc.org/rest.html>`_.
+
+.. code-block:: rest
+
+ r"""A one-line summary that does not use variable names or the
+ function name.
+
+ Several sentences providing an extended description. Refer to
+ variables using back-ticks, e.g. ``var``.
+
+ Parameters
+ ----------
+ var1 : array_like
+ Array_like means all those objects -- lists, nested lists, etc. --
+ that can be converted to an array. We can also refer to
+ variables like ``var1``.
+ var2 : int
+ The type above can either refer to an actual Python type
+ (e.g. ``int``), or describe the type of the variable in more
+ detail, e.g. ``(N,) ndarray`` or ``array_like``.
+ Long_variable_name : {'hi', 'ho'}, optional
+ Choices in brackets, default first when optional.
+
+ Returns
+ -------
+ describe : type
+ Explanation
+ output : type
+ Explanation
+ tuple : type
+ Explanation
+ items : type
+ even more explaining
+
+ Other Parameters
+ ----------------
+ only_seldom_used_keywords : type
+ Explanation
+ common_parameters_listed_above : type
+ Explanation
+
+ Raises
+ ------
+ BadException
+ Because you shouldn't have done that.
+
+ See Also
+ --------
+ otherfunc : relationship (optional)
+ newfunc : Relationship (optional), which could be fairly long, in which
+ case the line wraps here.
+ thirdfunc, fourthfunc, fifthfunc
+
+ Notes
+ -----
+ Notes about the implementation algorithm (if needed).
+
+ This can have multiple paragraphs.
+
+ You may include some math:
+
+ .. math:: X(e^{j\omega } ) = x(n)e^{ - j\omega n}
+
+ And even use a greek symbol like :math:`omega` inline.
+
+ References
+ ----------
+ Cite the relevant literature, e.g. [1]_. You may also cite these
+ references in the notes section above.
+
+ .. [1] O. McNoleg, "The integration of GIS, remote sensing,
+ expert systems and adaptive co-kriging for environmental habitat
+ modelling of the Highland Haggis using object-oriented, fuzzy-logic
+ and neural-network techniques," Computers & Geosciences, vol. 22,
+ pp. 585-588, 1996.
+
+ Examples
+ --------
+ These are written in doctest format, and should illustrate how to
+ use the function. Use the variables 'ds' for the dataset, 'pc' for
+ a plot collection, 'c' for a center, and 'L' for a vector.
+
+ >>> a=[1,2,3]
+ >>> print [x + 3 for x in a]
+ [4, 5, 6]
+ >>> print "a\n\nb"
+ a
+ b
+
+ """
+
+Variable Names and Enzo-isms
+----------------------------
+Avoid Enzo-isms. This includes but is not limited to:
+
+ * Hard-coding parameter names that are the same as those in Enzo. The
+ following translation table should be of some help. Note that the
+ parameters are now properties on a ``Dataset`` subclass: you access them
+ like ds.refine_by .
+
+ - ``RefineBy `` => `` refine_by``
+ - ``TopGridRank `` => `` dimensionality``
+ - ``TopGridDimensions `` => `` domain_dimensions``
+ - ``InitialTime `` => `` current_time``
+ - ``DomainLeftEdge `` => `` domain_left_edge``
+ - ``DomainRightEdge `` => `` domain_right_edge``
+ - ``CurrentTimeIdentifier `` => `` unique_identifier``
+ - ``CosmologyCurrentRedshift `` => `` current_redshift``
+ - ``ComovingCoordinates `` => `` cosmological_simulation``
+ - ``CosmologyOmegaMatterNow `` => `` omega_matter``
+ - ``CosmologyOmegaLambdaNow `` => `` omega_lambda``
+ - ``CosmologyHubbleConstantNow `` => `` hubble_constant``
+
+ * Do not assume that the domain runs from 0 .. 1. This is not true
+ everywhere.
+ * Variable names should be short but descriptive.
+ * No globals!
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b CREDITS
--- a/CREDITS
+++ b/CREDITS
@@ -4,32 +4,49 @@
Tom Abel (tabel at stanford.edu)
Gabriel Altay (gabriel.altay at gmail.com)
Kenza Arraki (karraki at gmail.com)
+ Kirk Barrow (kssbarrow at gatech.edu)
+ Ricarda Beckmann (Ricarda.Beckmann at astro.ox.ac.uk)
Elliott Biondo (biondo at wisc.edu)
Alex Bogert (fbogert at ucsc.edu)
+ André-Patrick Bubel (code at andre-bubel.de)
Pengfei Chen (madcpf at gmail.com)
+ Yi-Hao Chen (yihaochentw at gmail.com)
David Collins (dcollins4096 at gmail.com)
Brian Crosby (crosby.bd at gmail.com)
Andrew Cunningham (ajcunn at gmail.com)
Miguel de Val-Borro (miguel.deval at gmail.com)
+ Bili Dong (qobilidop at gmail.com)
+ Nicholas Earl (nchlsearl at gmail.com)
Hilary Egan (hilaryye at gmail.com)
+ Daniel Fenn (df11c at my.fsu.edu)
John Forces (jforbes at ucolick.org)
+ Adam Ginsburg (keflavich at gmail.com)
Sam Geen (samgeen at gmail.com)
Nathan Goldbaum (goldbaum at ucolick.org)
+ William Gray (graywilliamj at gmail.com)
Markus Haider (markus.haider at uibk.ac.at)
Eric Hallman (hallman13 at gmail.com)
+ David Hannasch (David.A.Hannasch at gmail.com)
Cameron Hummels (chummels at gmail.com)
+ Anni Järvenpää (anni.jarvenpaa at gmail.com)
+ Allyson Julian (astrohckr at gmail.com)
Christian Karch (chiffre at posteo.de)
+ Maximilian Katz (maximilian.katz at stonybrook.edu)
Ben W. Keller (kellerbw at mcmaster.ca)
Ji-hoon Kim (me at jihoonkim.org)
Steffen Klemer (sklemer at phys.uni-goettingen.de)
Kacper Kowalik (xarthisius.kk at gmail.com)
Mark Krumholz (mkrumhol at ucsc.edu)
Michael Kuhlen (mqk at astro.berkeley.edu)
+ Meagan Lang (langmm.astro at gmail.com)
+ Doris Lee (dorislee at berkeley.edu)
Eve Lee (elee at cita.utoronto.ca)
Sam Leitner (sam.leitner at gmail.com)
+ Stuart Levy (salevy at illinois.edu)
Yuan Li (yuan at astro.columbia.edu)
Chris Malone (chris.m.malone at gmail.com)
Josh Maloney (joshua.moloney at colorado.edu)
+ Jonah Miller (jonah.maxwell.miller at gmail.com)
Chris Moody (cemoody at ucsc.edu)
Stuart Mumford (stuart at mumford.me.uk)
Andrew Myers (atmyers at astro.berkeley.edu)
@@ -44,7 +61,9 @@
Mark Richardson (Mark.L.Richardson at asu.edu)
Thomas Robitaille (thomas.robitaille at gmail.com)
Anna Rosen (rosen at ucolick.org)
+ Chuck Rozhon (rozhon2 at illinois.edu)
Douglas Rudd (drudd at uchicago.edu)
+ Hsi-Yu Schive (hyschive at gmail.com)
Anthony Scopatz (scopatz at gmail.com)
Noel Scudder (noel.scudder at stonybrook.edu)
Pat Shriwise (shriwise at wisc.edu)
@@ -59,6 +78,8 @@
Ji Suoqing (jisuoqing at gmail.com)
Elizabeth Tasker (tasker at astro1.sci.hokudai.ac.jp)
Benjamin Thompson (bthompson2090 at gmail.com)
+ Robert Thompson (rthompsonj at gmail.com)
+ Joseph Tomlinson (jmtomlinson95 at gmail.com)
Stephanie Tonnesen (stonnes at gmail.com)
Matthew Turk (matthewturk at gmail.com)
Rich Wagner (rwagner at physics.ucsd.edu)
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b MANIFEST.in
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -1,14 +1,16 @@
-include distribute_setup.py README* CREDITS COPYING.txt CITATION requirements.txt optional-requirements.txt
-recursive-include yt/gui/reason/html *.html *.png *.ico *.js *.gif *.css
+include README* CREDITS COPYING.txt CITATION setupext.py CONTRIBUTING.rst
+include yt/visualization/mapserver/html/map_index.html
+include yt/visualization/mapserver/html/leaflet/*.css
+include yt/visualization/mapserver/html/leaflet/*.js
+include yt/visualization/mapserver/html/leaflet/images/*.png
+exclude scripts/pr_backport.py
recursive-include yt *.py *.pyx *.pxd *.h README* *.txt LICENSE* *.cu
-recursive-include doc *.rst *.txt *.py *.ipynb *.png *.jpg *.css *.inc *.html
+recursive-include doc *.rst *.txt *.py *.ipynb *.png *.jpg *.css *.html
recursive-include doc *.h *.c *.sh *.svgz *.pdf *.svg *.pyx
include doc/README doc/activate doc/activate.csh doc/cheatsheet.tex
include doc/extensions/README doc/Makefile
prune doc/source/reference/api/generated
prune doc/build
recursive-include yt/analysis_modules/halo_finding/rockstar *.py *.pyx
+recursive-include yt/visualization/volume_rendering/shaders *.fragmentshader *.vertexshader
prune yt/frontends/_skeleton
-prune tests
-graft yt/gui/reason/html/resources
-exclude clean.sh .hgchurn
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b appveyor.yml
--- /dev/null
+++ b/appveyor.yml
@@ -0,0 +1,38 @@
+# AppVeyor.com is a Continuous Integration service to build and run tests under
+# Windows
+
+environment:
+
+ global:
+ PYTHON: "C:\\Miniconda-x64"
+
+ matrix:
+
+ - PYTHON_VERSION: "2.7"
+
+ - PYTHON_VERSION: "3.5"
+
+
+platform:
+ -x64
+
+install:
+ - "SET PATH=%PYTHON%;%PYTHON%\\Scripts;%PATH%"
+
+ # Install the build and runtime dependencies of the project.
+ # Create a conda environment
+ - "conda create -q --yes -n test python=%PYTHON_VERSION%"
+ - "activate test"
+
+ # Check that we have the expected version of Python
+ - "python --version"
+
+ # Install specified version of numpy and dependencies
+ - "conda install -q --yes numpy nose setuptools ipython Cython sympy h5py matplotlib"
+ - "python setup.py develop"
+
+# Not a .NET project
+build: false
+
+test_script:
+ - "nosetests -e test_all_fields ."
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b clean.sh
--- a/clean.sh
+++ b/clean.sh
@@ -1,4 +1,1 @@
-find . -name "*.so" -exec rm -v {} \;
-find . -name "*.pyc" -exec rm -v {} \;
-find . -name "__config__.py" -exec rm -v {} \;
-rm -rvf build dist
+hg --config extensions.purge= purge --all yt
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b doc/cheatsheet.tex
--- a/doc/cheatsheet.tex
+++ b/doc/cheatsheet.tex
@@ -7,12 +7,12 @@
% To make this come out properly in landscape mode, do one of the following
% 1.
-% pdflatex latexsheet.tex
+% pdflatex cheatsheet.tex
%
% 2.
-% latex latexsheet.tex
-% dvips -P pdf -t landscape latexsheet.dvi
-% ps2pdf latexsheet.ps
+% latex cheatsheet.tex
+% dvips -P pdf -t landscape cheatsheet.dvi
+% ps2pdf cheatsheet.ps
% If you're reading this, be prepared for confusion. Making this was
@@ -45,7 +45,7 @@
% Turn off header and footer
\pagestyle{empty}
-
+
% Redefine section commands to use less space
\makeatletter
@@ -117,26 +117,26 @@
including a list of the available flags.
\texttt{iyt}\textemdash\ Load yt and IPython. \\
-\texttt{yt load} {\it dataset} \textemdash\ Load a single dataset. \\
+\texttt{yt load} \textit{dataset} \textemdash\ Load a single dataset. \\
\texttt{yt help} \textemdash\ Print yt help information. \\
-\texttt{yt stats} {\it dataset} \textemdash\ Print stats of a dataset. \\
+\texttt{yt stats} \textit{dataset} \textemdash\ Print stats of a dataset. \\
\texttt{yt update} \textemdash\ Update yt to most recent version.\\
\texttt{yt update --all} \textemdash\ Update yt and dependencies to most recent version. \\
\texttt{yt version} \textemdash\ yt installation information. \\
\texttt{yt notebook} \textemdash\ Run the IPython notebook server. \\
-\texttt{yt upload\_image} {\it image.png} \textemdash\ Upload PNG image to imgur.com. \\
-\texttt{yt upload\_notebook} {\it notebook.nb} \textemdash\ Upload IPython notebook to hub.yt-project.org.\\
-\texttt{yt plot} {\it dataset} \textemdash\ Create a set of images.\\
-\texttt{yt render} {\it dataset} \textemdash\ Create a simple
+\texttt{yt upload\_image} \textit{image.png} \textemdash\ Upload PNG image to imgur.com. \\
+\texttt{yt upload\_notebook} \textit{notebook.nb} \textemdash\ Upload IPython notebook to hub.yt-project.org.\\
+\texttt{yt plot} \textit{dataset} \textemdash\ Create a set of images.\\
+\texttt{yt render} \textit{dataset} \textemdash\ Create a simple
volume rendering. \\
-\texttt{yt mapserver} {\it dataset} \textemdash\ View a plot/projection in a Gmaps-like
+\texttt{yt mapserver} \textit{dataset} \textemdash\ View a plot/projection in a Gmaps-like
interface. \\
-\texttt{yt pastebin} {\it text.out} \textemdash\ Post text to the pastebin at
- paste.yt-project.org. \\
-\texttt{yt pastebin\_grab} {\it identifier} \textemdash\ Print content of pastebin to
+\texttt{yt pastebin} \textit{text.out} \textemdash\ Post text to the pastebin at
+ paste.yt-project.org. \\
+\texttt{yt pastebin\_grab} \textit{identifier} \textemdash\ Print content of pastebin to
STDOUT. \\
\texttt{yt bugreport} \textemdash\ Report a yt bug. \\
-\texttt{yt hop} {\it dataset} \textemdash\ Run hop on a dataset. \\
+\texttt{yt hop} \textit{dataset} \textemdash\ Run hop on a dataset. \\
\subsection{yt Imports}
In order to use yt, Python must load the relevant yt modules into memory.
@@ -144,15 +144,15 @@
used as part of a script.
\newlength{\MyLen}
\settowidth{\MyLen}{\texttt{letterpaper}/\texttt{a4paper} \ }
-\texttt{import yt} \textemdash\
+\texttt{import yt} \textemdash\
Load yt. \\
-\texttt{from yt.config import ytcfg} \textemdash\
+\texttt{from yt.config import ytcfg} \textemdash\
Used to set yt configuration options.
If used, must be called before importing any other module.\\
-\texttt{from yt.analysis\_modules.\emph{halo\_finding}.api import \textasteriskcentered} \textemdash\
+\texttt{from yt.analysis\_modules.\emph{halo\_finding}.api import \textasteriskcentered} \textemdash\
Load halo finding modules. Other modules
-are loaded in a similar way by swapping the
-{\em emphasized} text.
+are loaded in a similar way by swapping the
+\emph{emphasized} text.
See the \textbf{Analysis Modules} section for a listing and short descriptions of each.
\subsection{YTArray}
@@ -163,32 +163,32 @@
very brief list of some useful ones.
\settowidth{\MyLen}{\texttt{multicol} }\\
\texttt{v = a.in\_cgs()} \textemdash\ Return the array in CGS units \\
-\texttt{v = a.in\_units('Msun/pc**3')} \textemdash\ Return the array in solar masses per cubic parsec \\
+\texttt{v = a.in\_units('Msun/pc**3')} \textemdash\ Return the array in solar masses per cubic parsec \\
\texttt{v = a.max(), a.min()} \textemdash\ Return maximum, minimum of \texttt{a}. \\
\texttt{index = a.argmax(), a.argmin()} \textemdash\ Return index of max,
min value of \texttt{a}.\\
-\texttt{v = a[}{\it index}\texttt{]} \textemdash\ Select a single value from \texttt{a} at location {\it index}.\\
-\texttt{b = a[}{\it i:j}\texttt{]} \textemdash\ Select the slice of values from
+\texttt{v = a[}\textit{index}\texttt{]} \textemdash\ Select a single value from \texttt{a} at location \textit{index}.\\
+\texttt{b = a[}\textit{i:j}\texttt{]} \textemdash\ Select the slice of values from
\texttt{a} between
-locations {\it i} to {\it j-1} saved to a new Numpy array \texttt{b} with length {\it j-i}. \\
+locations \textit{i} to \textit{j-1} saved to a new Numpy array \texttt{b} with length \textit{j-i}. \\
\texttt{sel = (a > const)} \textemdash\ Create a new boolean Numpy array
\texttt{sel}, of the same shape as \texttt{a},
that marks which values of \texttt{a > const}. Other operators (e.g. \textless, !=, \%) work as well.\\
\texttt{b = a[sel]} \textemdash\ Create a new Numpy array \texttt{b} made up of
elements from \texttt{a} that correspond to elements of \texttt{sel}
-that are {\it True}. In the above example \texttt{b} would be all elements of \texttt{a} that are greater than \texttt{const}.\\
-\texttt{a.write\_hdf5({\it filename.h5})} \textemdash\ Save \texttt{a} to the hdf5 file {\it filename.h5}.\\
+that are \textit{True}. In the above example \texttt{b} would be all elements of \texttt{a} that are greater than \texttt{const}.\\
+\texttt{a.write\_hdf5(\textit{filename.h5})} \textemdash\ Save \texttt{a} to the hdf5 file \textit{filename.h5}.\\
\subsection{IPython Tips}
\settowidth{\MyLen}{\texttt{multicol} }
These tips work if IPython has been loaded, typically either by invoking
\texttt{iyt} or \texttt{yt load} on the command line, or using the IPython notebook (\texttt{yt notebook}).
\texttt{Tab complete} \textemdash\ IPython will attempt to auto-complete a
-variable or function name when the \texttt{Tab} key is pressed, e.g. {\it HaloFi}\textendash\texttt{Tab} would auto-complete
-to {\it HaloFinder}. This also works with imports, e.g. {\it from numpy.random.}\textendash\texttt{Tab}
+variable or function name when the \texttt{Tab} key is pressed, e.g. \textit{HaloFi}\textendash\texttt{Tab} would auto-complete
+to \textit{HaloFinder}. This also works with imports, e.g. \textit{from numpy.random.}\textendash\texttt{Tab}
would give you a list of random functions (note the trailing period before hitting \texttt{Tab}).\\
\texttt{?, ??} \textemdash\ Appending one or two question marks at the end of any object gives you
-detailed information about it, e.g. {\it variable\_name}?.\\
+detailed information about it, e.g. \textit{variable\_name}?.\\
Below a few IPython ``magics'' are listed, which are IPython-specific shortcut commands.\\
\texttt{\%paste} \textemdash\ Paste content from the system clipboard into the IPython shell.\\
\texttt{\%hist} \textemdash\ Print recent command history.\\
@@ -204,40 +204,40 @@
\subsection{Load and Access Data}
The first step in using yt is to reference a simulation snapshot.
-After that, simulation data is generally accessed in yt using {\it Data Containers} which are Python objects
+After that, simulation data is generally accessed in yt using \textit{Data Containers} which are Python objects
that define a region of simulation space from which data should be selected.
\settowidth{\MyLen}{\texttt{multicol} }
-\texttt{ds = yt.load(}{\it dataset}\texttt{)} \textemdash\ Reference a single snapshot.\\
+\texttt{ds = yt.load(}\textit{dataset}\texttt{)} \textemdash\ Reference a single snapshot.\\
\texttt{dd = ds.all\_data()} \textemdash\ Select the entire volume.\\
-\texttt{a = dd[}{\it field\_name}\texttt{]} \textemdash\ Copies the contents of {\it field} into the
+\texttt{a = dd[}\textit{field\_name}\texttt{]} \textemdash\ Copies the contents of \textit{field} into the
YTArray \texttt{a}. Similarly for other data containers.\\
\texttt{ds.field\_list} \textemdash\ A list of available fields in the snapshot. \\
\texttt{ds.derived\_field\_list} \textemdash\ A list of available derived fields
in the snapshot. \\
\texttt{val, loc = ds.find\_max("Density")} \textemdash\ Find the \texttt{val}ue of
the maximum of the field \texttt{Density} and its \texttt{loc}ation. \\
-\texttt{sp = ds.sphere(}{\it cen}\texttt{,}{\it radius}\texttt{)} \textemdash\ Create a spherical data
-container. {\it cen} may be a coordinate, or ``max'' which
-centers on the max density point. {\it radius} may be a float in
-code units or a tuple of ({\it length, unit}).\\
+\texttt{sp = ds.sphere(}\textit{cen}\texttt{,}\textit{radius}\texttt{)} \textemdash\ Create a spherical data
+container. \textit{cen} may be a coordinate, or ``max'' which
+centers on the max density point. \textit{radius} may be a float in
+code units or a tuple of (\textit{length, unit}).\\
-\texttt{re = ds.region({\it cen}, {\it left edge}, {\it right edge})} \textemdash\ Create a
-rectilinear data container. {\it cen} is required but not used.
-{\it left} and {\it right edge} are coordinate values that define the region.
+\texttt{re = ds.region(\textit{cen}, \textit{left edge}, \textit{right edge})} \textemdash\ Create a
+rectilinear data container. \textit{cen} is required but not used.
+\textit{left} and \textit{right edge} are coordinate values that define the region.
-\texttt{di = ds.disk({\it cen}, {\it normal}, {\it radius}, {\it height})} \textemdash\
-Create a cylindrical data container centered at {\it cen} along the
-direction set by {\it normal},with total length
- 2$\times${\it height} and with radius {\it radius}. \\
-
-\texttt{ds.save\_object(sp, {\it ``sp\_for\_later''})} \textemdash\ Save an object (\texttt{sp}) for later use.\\
-\texttt{sp = ds.load\_object({\it ``sp\_for\_later''})} \textemdash\ Recover a saved object.\\
+\texttt{di = ds.disk(\textit{cen}, \textit{normal}, \textit{radius}, \textit{height})} \textemdash\
+Create a cylindrical data container centered at \textit{cen} along the
+direction set by \textit{normal},with total length
+ 2$\times$\textit{height} and with radius \textit{radius}. \\
+
+\texttt{ds.save\_object(sp, \textit{``sp\_for\_later''})} \textemdash\ Save an object (\texttt{sp}) for later use.\\
+\texttt{sp = ds.load\_object(\textit{``sp\_for\_later''})} \textemdash\ Recover a saved object.\\
\subsection{Defining New Fields}
-\texttt{yt} expects on-disk fields, fields generated on-demand and in-memory.
+\texttt{yt} expects on-disk fields, fields generated on-demand and in-memory.
Field can either be created before a dataset is loaded using \texttt{add\_field}:
-\texttt{def \_metal\_mass({\it field},{\it data})}\\
+\texttt{def \_metal\_mass(\textit{field},\textit{data})}\\
\texttt{\hspace{4 mm} return data["metallicity"]*data["cell\_mass"]}\\
\texttt{add\_field("metal\_mass", units='g', function=\_metal\_mass)}\\
Or added to an existing dataset using \texttt{ds.add\_field}:
@@ -245,34 +245,34 @@
\subsection{Slices and Projections}
\settowidth{\MyLen}{\texttt{multicol} }
-\texttt{slc = yt.SlicePlot(ds, {\it axis or normal vector}, {\it field}, {\it center=}, {\it width=}, {\it weight\_field=}, {\it additional parameters})} \textemdash\ Make a slice plot
-perpendicular to {\it axis} (specified via 'x', 'y', or 'z') or a normal vector for an off-axis slice of {\it field} weighted by {\it weight\_field} at (code-units) {\it center} with
-{\it width} in code units or a (value, unit) tuple. Hint: try {\it yt.SlicePlot?} in IPython to see additional parameters.\\
-\texttt{slc.save({\it file\_prefix})} \textemdash\ Save the slice to a png with name prefix {\it file\_prefix}.
+\texttt{slc = yt.SlicePlot(ds, \textit{axis or normal vector}, \textit{field}, \textit{center=}, \textit{width=}, \textit{weight\_field=}, \textit{additional parameters})} \textemdash\ Make a slice plot
+perpendicular to \textit{axis} (specified via 'x', 'y', or 'z') or a normal vector for an off-axis slice of \textit{field} weighted by \textit{weight\_field} at (code-units) \textit{center} with
+\textit{width} in code units or a (value, unit) tuple. Hint: try \textit{yt.SlicePlot?} in IPython to see additional parameters.\\
+\texttt{slc.save(\textit{file\_prefix})} \textemdash\ Save the slice to a png with name prefix \textit{file\_prefix}.
\texttt{.save()} works similarly for the commands below.\\
-\texttt{prj = yt.ProjectionPlot(ds, {\it axis}, {\it field}, {\it addit. params})} \textemdash\ Make a projection. \\
-\texttt{prj = yt.OffAxisProjectionPlot(ds, {\it normal}, {\it fields}, {\it center=}, {\it width=}, {\it depth=},{\it north\_vector=},{\it weight\_field=})} \textemdash Make an off axis projection. Note this takes an array of fields. \\
+\texttt{prj = yt.ProjectionPlot(ds, \textit{axis}, \textit{field}, \textit{addit. params})} \textemdash\ Make a projection. \\
+\texttt{prj = yt.OffAxisProjectionPlot(ds, \textit{normal}, \textit{fields}, \textit{center=}, \textit{width=}, \textit{depth=},\textit{north\_vector=},\textit{weight\_field=})} \textemdash Make an off axis projection. Note this takes an array of fields. \\
\subsection{Plot Annotations}
\settowidth{\MyLen}{\texttt{multicol} }
-Plot callbacks are functions itemized in a registry that is attached to every plot object. They can be accessed and then called like \texttt{ prj.annotate\_velocity(factor=16, normalize=False)}. Most callbacks also accept a {\it plot\_args} dict that is fed to matplotlib annotator. \\
-\texttt{velocity({\it factor=},{\it scale=},{\it scale\_units=}, {\it normalize=})} \textemdash\ Uses field "x-velocity" to draw quivers\\
-\texttt{magnetic\_field({\it factor=},{\it scale=},{\it scale\_units=}, {\it normalize=})} \textemdash\ Uses field "Bx" to draw quivers\\
-\texttt{quiver({\it field\_x},{\it field\_y},{\it factor=},{\it scale=},{\it scale\_units=}, {\it normalize=})} \\
-\texttt{contour({\it field=},{\it ncont=},{\it factor=},{\it clim=},{\it take\_log=}, {\it additional parameters})} \textemdash Plots a number of contours {\it ncont} to interpolate {\it field} optionally using {\it take\_log}, upper and lower {\it c}ontour{\it lim}its and {\it factor} number of points in the interpolation.\\
-\texttt{grids({\it alpha=}, {\it draw\_ids=}, {\it periodic=}, {\it min\_level=}, {\it max\_level=})} \textemdash Add grid boundaries. \\
-\texttt{streamlines({\it field\_x},{\it field\_y},{\it factor=},{\it density=})}\\
-\texttt{clumps({\it clumplist})} \textemdash\ Generate {\it clumplist} using the clump finder and plot. \\
-\texttt{arrow({\it pos}, {\it code\_size})} Add an arrow at a {\it pos}ition. \\
-\texttt{point({\it pos}, {\it text})} \textemdash\ Add text at a {\it pos}ition. \\
-\texttt{marker({\it pos}, {\it marker=})} \textemdash\ Add a matplotlib-defined marker at a {\it pos}ition. \\
-\texttt{sphere({\it center}, {\it radius}, {\it text=})} \textemdash\ Draw a circle and append {\it text}.\\
-\texttt{hop\_circles({\it hop\_output}, {\it max\_number=}, {\it annotate=}, {\it min\_size=}, {\it max\_size=}, {\it font\_size=}, {\it print\_halo\_size=}, {\it fixed\_radius=}, {\it min\_mass=}, {\it print\_halo\_mass=}, {\it width=})} \textemdash\ Draw a halo, printing it's ID, mass, clipping halos depending on number of particles ({\it size}) and optionally fixing the drawn circle radius to be constant for all halos.\\
-\texttt{hop\_particles({\it hop\_output},{\it max\_number=},{\it p\_size=},\\
-{\it min\_size},{\it alpha=})} \textemdash\ Draw particle positions for member halos with a certain number of pixels per particle.\\
-\texttt{particles({\it width},{\it p\_size=},{\it col=}, {\it marker=}, {\it stride=}, {\it ptype=}, {\it stars\_only=}, {\it dm\_only=}, {\it minimum\_mass=}, {\it alpha=})} \textemdash\ Draw particles of {\it p\_size} pixels in a slab of {\it width} with {\it col}or using a matplotlib {\it marker} plotting only every {\it stride} number of particles.\\
-\texttt{title({\it text})}\\
+Plot callbacks are functions itemized in a registry that is attached to every plot object. They can be accessed and then called like \texttt{ prj.annotate\_velocity(factor=16, normalize=False)}. Most callbacks also accept a \textit{plot\_args} dict that is fed to matplotlib annotator. \\
+\texttt{velocity(\textit{factor=},\textit{scale=},\textit{scale\_units=}, \textit{normalize=})} \textemdash\ Uses field "x-velocity" to draw quivers\\
+\texttt{magnetic\_field(\textit{factor=},\textit{scale=},\textit{scale\_units=}, \textit{normalize=})} \textemdash\ Uses field "Bx" to draw quivers\\
+\texttt{quiver(\textit{field\_x},\textit{field\_y},\textit{factor=},\textit{scale=},\textit{scale\_units=}, \textit{normalize=})} \\
+\texttt{contour(\textit{field=},\textit{ncont=},\textit{factor=},\textit{clim=},\textit{take\_log=}, \textit{additional parameters})} \textemdash Plots a number of contours \textit{ncont} to interpolate \textit{field} optionally using \textit{take\_log}, upper and lower \textit{c}ontour\textit{lim}its and \textit{factor} number of points in the interpolation.\\
+\texttt{grids(\textit{alpha=}, \textit{draw\_ids=}, \textit{periodic=}, \textit{min\_level=}, \textit{max\_level=})} \textemdash Add grid boundaries. \\
+\texttt{streamlines(\textit{field\_x},\textit{field\_y},\textit{factor=},\textit{density=})}\\
+\texttt{clumps(\textit{clumplist})} \textemdash\ Generate \textit{clumplist} using the clump finder and plot. \\
+\texttt{arrow(\textit{pos}, \textit{code\_size})} Add an arrow at a \textit{pos}ition. \\
+\texttt{point(\textit{pos}, \textit{text})} \textemdash\ Add text at a \textit{pos}ition. \\
+\texttt{marker(\textit{pos}, \textit{marker=})} \textemdash\ Add a matplotlib-defined marker at a \textit{pos}ition. \\
+\texttt{sphere(\textit{center}, \textit{radius}, \textit{text=})} \textemdash\ Draw a circle and append \textit{text}.\\
+\texttt{hop\_circles(\textit{hop\_output}, \textit{max\_number=}, \textit{annotate=}, \textit{min\_size=}, \textit{max\_size=}, \textit{font\_size=}, \textit{print\_halo\_size=}, \textit{fixed\_radius=}, \textit{min\_mass=}, \textit{print\_halo\_mass=}, \textit{width=})} \textemdash\ Draw a halo, printing it's ID, mass, clipping halos depending on number of particles (\textit{size}) and optionally fixing the drawn circle radius to be constant for all halos.\\
+\texttt{hop\_particles(\textit{hop\_output},\textit{max\_number=},\textit{p\_size=},\\
+\textit{min\_size},\textit{alpha=})} \textemdash\ Draw particle positions for member halos with a certain number of pixels per particle.\\
+\texttt{particles(\textit{width},\textit{p\_size=},\textit{col=}, \textit{marker=}, \textit{stride=}, \textit{ptype=}, \textit{stars\_only=}, \textit{dm\_only=}, \textit{minimum\_mass=}, \textit{alpha=})} \textemdash\ Draw particles of \textit{p\_size} pixels in a slab of \textit{width} with \textit{col}or using a matplotlib \textit{marker} plotting only every \textit{stride} number of particles.\\
+\texttt{title(\textit{text})}\\
\subsection{The $\sim$/.yt/ Directory}
\settowidth{\MyLen}{\texttt{multicol} }
@@ -297,12 +297,12 @@
\subsection{Parallel Analysis}
-\settowidth{\MyLen}{\texttt{multicol}}
+\settowidth{\MyLen}{\texttt{multicol}}
Nearly all of yt is parallelized using
-MPI. The {\it mpi4py} package must be installed for parallelism in yt. To
-install {\it pip install mpi4py} on the command line usually works.
+MPI\@. The \textit{mpi4py} package must be installed for parallelism in yt. To
+install \textit{pip install mpi4py} on the command line usually works.
Execute python in parallel similar to this:\\
-{\it mpirun -n 12 python script.py}\\
+\textit{mpirun -n 12 python script.py}\\
The file \texttt{script.py} must call the \texttt{yt.enable\_parallelism()} to
turn on yt's parallelism. If this doesn't happen, all cores will execute the
same serial yt script. This command may differ for each system on which you use
@@ -320,12 +320,12 @@
\texttt{hg clone https://bitbucket.org/yt\_analysis/yt} \textemdash\ Clone a copy of yt. \\
\texttt{hg status} \textemdash\ Files changed in working directory.\\
\texttt{hg diff} \textemdash\ Print diff of all changed files in working directory. \\
-\texttt{hg diff -r{\it RevX} -r{\it RevY}} \textemdash\ Print diff of all changes between revision {\it RevX} and {\it RevY}.\\
+\texttt{hg diff -r\textit{RevX} -r\textit{RevY}} \textemdash\ Print diff of all changes between revision \textit{RevX} and \textit{RevY}.\\
\texttt{hg log} \textemdash\ History of changes.\\
-\texttt{hg cat -r{\it RevX file}} \textemdash\ Print the contents of {\it file} from revision {\it RevX}.\\
+\texttt{hg cat -r\textit{RevX file}} \textemdash\ Print the contents of \textit{file} from revision \textit{RevX}.\\
\texttt{hg heads} \textemdash\ Print all the current heads. \\
-\texttt{hg revert -r{\it RevX file}} \textemdash\ Revert {\it file} to revision {\it RevX}. On-disk changed version is
-moved to {\it file.orig}. \\
+\texttt{hg revert -r\textit{RevX file}} \textemdash\ Revert \textit{file} to revision \textit{RevX}. On-disk changed version is
+moved to \textit{file.orig}. \\
\texttt{hg commit} \textemdash\ Commit changes to repository. \\
\texttt{hg push} \textemdash\ Push changes to default remote repository. \\
\texttt{hg pull} \textemdash\ Pull changes from default remote repository. \\
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b doc/coding_styleguide.txt
--- a/doc/coding_styleguide.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-Style Guide for Coding in yt
-============================
-
-Coding Style Guide
-------------------
-
- * In general, follow PEP-8 guidelines.
- http://www.python.org/dev/peps/pep-0008/
- * Classes are ConjoinedCapitals, methods and functions are
- lowercase_with_underscores.
- * Use 4 spaces, not tabs, to represent indentation.
- * Line widths should not be more than 80 characters.
- * Do not use nested classes unless you have a very good reason to, such as
- requiring a namespace or class-definition modification. Classes should live
- at the top level. __metaclass__ is exempt from this.
- * Do not use unnecessary parenthesis in conditionals. if((something) and
- (something_else)) should be rewritten as if something and something_else.
- Python is more forgiving than C.
- * Avoid copying memory when possible. For example, don't do
- "a = a.reshape(3,4)" when "a.shape = (3,4)" will do, and "a = a * 3" should
- be "np.multiply(a, 3, a)".
- * In general, avoid all double-underscore method names: __something is usually
- unnecessary.
- * When writing a subclass, use the super built-in to access the super class,
- rather than explicitly. Ex: "super(SpecialGrid, self).__init__()" rather than
- "SpecialGrid.__init__()".
- * Doc strings should describe input, output, behavior, and any state changes
- that occur on an object. See the file `doc/docstring_example.txt` for a
- fiducial example of a docstring.
-
-API Guide
----------
-
- * Do not import "*" from anything other than "yt.funcs".
- * Internally, only import from source files directly -- instead of:
-
- from yt.visualization.api import ProjectionPlot
-
- do:
-
- from yt.visualization.plot_window import ProjectionPlot
-
- * Numpy is to be imported as "np", after a long time of using "na".
- * Do not use too many keyword arguments. If you have a lot of keyword
- arguments, then you are doing too much in __init__ and not enough via
- parameter setting.
- * In function arguments, place spaces before commas. def something(a,b,c)
- should be def something(a, b, c).
- * Don't create a new class to replicate the functionality of an old class --
- replace the old class. Too many options makes for a confusing user
- experience.
- * Parameter files external to yt are a last resort.
- * The usage of the **kwargs construction should be avoided. If they cannot
- be avoided, they must be explained, even if they are only to be passed on to
- a nested function.
-
-Variable Names and Enzo-isms
-----------------------------
-
- * Avoid Enzo-isms. This includes but is not limited to:
- * Hard-coding parameter names that are the same as those in Enzo. The
- following translation table should be of some help. Note that the
- parameters are now properties on a Dataset subclass: you access them
- like ds.refine_by .
- * RefineBy => refine_by
- * TopGridRank => dimensionality
- * TopGridDimensions => domain_dimensions
- * InitialTime => current_time
- * DomainLeftEdge => domain_left_edge
- * DomainRightEdge => domain_right_edge
- * CurrentTimeIdentifier => unique_identifier
- * CosmologyCurrentRedshift => current_redshift
- * ComovingCoordinates => cosmological_simulation
- * CosmologyOmegaMatterNow => omega_matter
- * CosmologyOmegaLambdaNow => omega_lambda
- * CosmologyHubbleConstantNow => hubble_constant
- * Do not assume that the domain runs from 0 .. 1. This is not true
- everywhere.
- * Variable names should be short but descriptive.
- * No globals!
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b doc/docstring_example.txt
--- a/doc/docstring_example.txt
+++ /dev/null
@@ -1,86 +0,0 @@
- r"""A one-line summary that does not use variable names or the
- function name.
-
- Several sentences providing an extended description. Refer to
- variables using back-ticks, e.g. `var`.
-
- Parameters
- ----------
- var1 : array_like
- Array_like means all those objects -- lists, nested lists, etc. --
- that can be converted to an array. We can also refer to
- variables like `var1`.
- var2 : int
- The type above can either refer to an actual Python type
- (e.g. ``int``), or describe the type of the variable in more
- detail, e.g. ``(N,) ndarray`` or ``array_like``.
- Long_variable_name : {'hi', 'ho'}, optional
- Choices in brackets, default first when optional.
-
- Returns
- -------
- describe : type
- Explanation
- output : type
- Explanation
- tuple : type
- Explanation
- items : type
- even more explaining
-
- Other Parameters
- ----------------
- only_seldom_used_keywords : type
- Explanation
- common_parameters_listed_above : type
- Explanation
-
- Raises
- ------
- BadException
- Because you shouldn't have done that.
-
- See Also
- --------
- otherfunc : relationship (optional)
- newfunc : Relationship (optional), which could be fairly long, in which
- case the line wraps here.
- thirdfunc, fourthfunc, fifthfunc
-
- Notes
- -----
- Notes about the implementation algorithm (if needed).
-
- This can have multiple paragraphs.
-
- You may include some math:
-
- .. math:: X(e^{j\omega } ) = x(n)e^{ - j\omega n}
-
- And even use a greek symbol like :math:`omega` inline.
-
- References
- ----------
- Cite the relevant literature, e.g. [1]_. You may also cite these
- references in the notes section above.
-
- .. [1] O. McNoleg, "The integration of GIS, remote sensing,
- expert systems and adaptive co-kriging for environmental habitat
- modelling of the Highland Haggis using object-oriented, fuzzy-logic
- and neural-network techniques," Computers & Geosciences, vol. 22,
- pp. 585-588, 1996.
-
- Examples
- --------
- These are written in doctest format, and should illustrate how to
- use the function. Use the variables 'ds' for the dataset, 'pc' for
- a plot collection, 'c' for a center, and 'L' for a vector.
-
- >>> a=[1,2,3]
- >>> print [x + 3 for x in a]
- [4, 5, 6]
- >>> print "a\n\nb"
- a
- b
-
- """
diff -r bdea84d950999973d7b80cba34acc4c70b62a925 -r 5be60a71c30cdd72458279ab523884317d6ba41b doc/extensions/notebook_sphinxext.py
--- a/doc/extensions/notebook_sphinxext.py
+++ /dev/null
@@ -1,241 +0,0 @@
-import errno
-import os
-import shutil
-import string
-import re
-import tempfile
-import uuid
-from sphinx.util.compat import Directive
-from docutils import nodes
-from docutils.parsers.rst import directives
-from IPython.config import Config
-from IPython.nbconvert import html, python
-from IPython.nbformat import current as nbformat
-from runipy.notebook_runner import NotebookRunner, NotebookError
-
-class NotebookDirective(Directive):
- """Insert an evaluated notebook into a document
-
- This uses runipy and nbconvert to transform a path to an unevaluated notebook
- into html suitable for embedding in a Sphinx document.
- """
- required_arguments = 1
- optional_arguments = 1
- option_spec = {'skip_exceptions': directives.flag}
- final_argument_whitespace = True
-
- def run(self): # check if there are spaces in the notebook name
- nb_path = self.arguments[0]
- if ' ' in nb_path: raise ValueError(
- "Due to issues with docutils stripping spaces from links, white "
- "space is not allowed in notebook filenames '{0}'".format(nb_path))
- # check if raw html is supported
- if not self.state.document.settings.raw_enabled:
- raise self.warning('"%s" directive disabled.' % self.name)
-
- cwd = os.getcwd()
- tmpdir = tempfile.mkdtemp()
- os.chdir(tmpdir)
-
- # get path to notebook
- nb_filename = self.arguments[0]
- nb_basename = os.path.basename(nb_filename)
- rst_file = self.state_machine.document.attributes['source']
- rst_dir = os.path.abspath(os.path.dirname(rst_file))
- nb_abs_path = os.path.abspath(os.path.join(rst_dir, nb_filename))
-
- # Move files around.
- rel_dir = os.path.relpath(rst_dir, setup.confdir)
- dest_dir = os.path.join(setup.app.builder.outdir, rel_dir)
- dest_path = os.path.join(dest_dir, nb_basename)
-
- image_dir, image_rel_dir = make_image_dir(setup, rst_dir)
-
- # Ensure desination build directory exists
- thread_safe_mkdir(os.path.dirname(dest_path))
-
- # Copy unevaluated notebook
- shutil.copyfile(nb_abs_path, dest_path)
-
- # Construct paths to versions getting copied over
- dest_path_eval = string.replace(dest_path, '.ipynb', '_evaluated.ipynb')
- dest_path_script = string.replace(dest_path, '.ipynb', '.py')
- rel_path_eval = string.replace(nb_basename, '.ipynb', '_evaluated.ipynb')
- rel_path_script = string.replace(nb_basename, '.ipynb', '.py')
-
- # Create python script vesion
- script_text = nb_to_python(nb_abs_path)
- f = open(dest_path_script, 'w')
- f.write(script_text.encode('utf8'))
- f.close()
-
- skip_exceptions = 'skip_exceptions' in self.options
-
- ret = evaluate_notebook(
- nb_abs_path, dest_path_eval, skip_exceptions=skip_exceptions)
-
- try:
- evaluated_text, resources = ret
- evaluated_text = write_notebook_output(
- resources, image_dir, image_rel_dir, evaluated_text)
- except ValueError:
- # This happens when a notebook raises an unhandled exception
- evaluated_text = ret
-
- # Create link to notebook and script files
- link_rst = "(" + \
- formatted_link(nb_basename) + "; " + \
- formatted_link(rel_path_eval) + "; " + \
- formatted_link(rel_path_script) + \
- ")"
-
- self.state_machine.insert_input([link_rst], rst_file)
-
- # create notebook node
- attributes = {'format': 'html', 'source': 'nb_path'}
- nb_node = notebook_node('', evaluated_text, **attributes)
- (nb_node.source, nb_node.line) = \
- self.state_machine.get_source_and_line(self.lineno)
-
- # add dependency
- self.state.document.settings.record_dependencies.add(nb_abs_path)
-
- # clean up
- os.chdir(cwd)
- shutil.rmtree(tmpdir, True)
-
- return [nb_node]
-
-
-class notebook_node(nodes.raw):
- pass
-
-def nb_to_python(nb_path):
- """convert notebook to python script"""
- exporter = python.PythonExporter()
- output, resources = exporter.from_filename(nb_path)
- return output
-
-def nb_to_html(nb_path):
- """convert notebook to html"""
- c = Config({'ExtractOutputPreprocessor':{'enabled':True}})
-
- exporter = html.HTMLExporter(template_file='full', config=c)
- notebook = nbformat.read(open(nb_path), 'json')
- output, resources = exporter.from_notebook_node(notebook)
- header = output.split('<head>', 1)[1].split('</head>',1)[0]
- body = output.split('<body>', 1)[1].split('</body>',1)[0]
-
- # http://imgur.com/eR9bMRH
- header = header.replace('<style', '<style scoped="scoped"')
- header = header.replace('body {\n overflow: visible;\n padding: 8px;\n}\n',
- '')
- header = header.replace("code,pre{", "code{")
-
- # Filter out styles that conflict with the sphinx theme.
- filter_strings = [
- 'navbar',
- 'body{',
- 'alert{',
- 'uneditable-input{',
- 'collapse{',
- ]
-
- filter_strings.extend(['h%s{' % (i+1) for i in range(6)])
-
- line_begin = [
- 'pre{',
- 'p{margin'
- ]
-
- filterfunc = lambda x: not any([s in x for s in filter_strings])
- header_lines = filter(filterfunc, header.split('\n'))
-
- filterfunc = lambda x: not any([x.startswith(s) for s in line_begin])
- header_lines = filter(filterfunc, header_lines)
-
- header = '\n'.join(header_lines)
-
- # concatenate raw html lines
- lines = ['<div class="ipynotebook">']
- lines.append(header)
- lines.append(body)
- lines.append('</div>')
- return '\n'.join(lines), resources
-
-def evaluate_notebook(nb_path, dest_path=None, skip_exceptions=False):
- # Create evaluated version and save it to the dest path.
- notebook = nbformat.read(open(nb_path), 'json')
- nb_runner = NotebookRunner(notebook, pylab=False)
- try:
- nb_runner.run_notebook(skip_exceptions=skip_exceptions)
- except NotebookError as e:
- print('')
- print(e)
- # Return the traceback, filtering out ANSI color codes.
- # http://stackoverflow.com/questions/13506033/filtering-out-ansi-escape-sequences
- return "Notebook conversion failed with the " \
- "following traceback: \n%s" % \
- re.sub(r'\\033[\[\]]([0-9]{1,2}([;@][0-9]{0,2})*)*[mKP]?', '',
- str(e))
-
- if dest_path is None:
- dest_path = 'temp_evaluated.ipynb'
- nbformat.write(nb_runner.nb, open(dest_path, 'w'), 'json')
- ret = nb_to_html(dest_path)
- if dest_path is 'temp_evaluated.ipynb':
- os.remove(dest_path)
- return ret
-
-def formatted_link(path):
- return "`%s <%s>`__" % (os.path.basename(path), path)
-
-def visit_notebook_node(self, node):
- self.visit_raw(node)
-
-def depart_notebook_node(self, node):
- self.depart_raw(node)
-
-def setup(app):
- setup.app = app
- setup.config = app.config
- setup.confdir = app.confdir
-
- app.add_node(notebook_node,
- html=(visit_notebook_node, depart_notebook_node))
-
- app.add_directive('notebook', NotebookDirective)
-
- retdict = dict(
- version='0.1',
- parallel_read_safe=True,
- parallel_write_safe=True
- )
-
- return retdict
-
-def make_image_dir(setup, rst_dir):
- image_dir = setup.app.builder.outdir + os.path.sep + '_images'
- rel_dir = os.path.relpath(setup.confdir, rst_dir)
- image_rel_dir = rel_dir + os.path.sep + '_images'
- thread_safe_mkdir(image_dir)
- return image_dir, image_rel_dir
-
-def write_notebook_output(resources, image_dir, image_rel_dir, evaluated_text):
- my_uuid = uuid.uuid4().hex
-
- for output in resources['outputs']:
- new_name = image_dir + os.path.sep + my_uuid + output
- new_relative_name = image_rel_dir + os.path.sep + my_uuid + output
- evaluated_text = evaluated_text.replace(output, new_relative_name)
- with open(new_name, 'wb') as f:
- f.write(resources['outputs'][output])
- return evaluated_text
-
-def thread_safe_mkdir(dirname):
- try:
- os.makedirs(dirname)
- except OSError as e:
- if e.errno != errno.EEXIST:
- raise
- pass
This diff is so big that we needed to truncate the remainder.
https://bitbucket.org/yt_analysis/yt/commits/c07d1b4bd656/
Changeset: c07d1b4bd656
Branch: stable
User: ngoldbaum
Date: 2016-07-24 15:34:12+00:00
Summary: Readding cookbook content that merging missed for some reason.
Affected #: 1 file
diff -r 5be60a71c30cdd72458279ab523884317d6ba41b -r c07d1b4bd6563ba5f526372aacbac0ce99086923 doc/source/cookbook/calculating_information.rst
--- a/doc/source/cookbook/calculating_information.rst
+++ b/doc/source/cookbook/calculating_information.rst
@@ -56,6 +56,16 @@
.. yt_cookbook:: simulation_analysis.py
+Smoothed Fields
+~~~~~~~~~~~~~~~
+
+This recipe demonstrates how to create a smoothed field,
+corresponding to a user-created derived field, using the
+:meth:`~yt.fields.particle_fields.add_volume_weighted_smoothed_field` method.
+See :ref:`gadget-notebook` for how to work with Gadget data.
+
+.. yt_cookbook:: smoothed_field.py
+
.. _cookbook-time-series-analysis:
https://bitbucket.org/yt_analysis/yt/commits/7edbfde96c3d/
Changeset: 7edbfde96c3d
Branch: stable
User: ngoldbaum
Date: 2016-07-24 15:38:05+00:00
Summary: Updating version numbers
Affected #: 3 files
diff -r c07d1b4bd6563ba5f526372aacbac0ce99086923 -r 7edbfde96c3d55b227194394f46c0b2e6ed2b961 doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -67,9 +67,9 @@
# built documents.
#
# The short X.Y version.
-version = '3.3-dev'
+version = '3.3.0'
# The full version, including alpha/beta/rc tags.
-release = '3.2.3'
+release = '3.3.0'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
diff -r c07d1b4bd6563ba5f526372aacbac0ce99086923 -r 7edbfde96c3d55b227194394f46c0b2e6ed2b961 setup.py
--- a/setup.py
+++ b/setup.py
@@ -50,7 +50,7 @@
SHADERS_FILES = glob.glob(os.path.join(SHADERS_DIR, "*.vertexshader")) + \
glob.glob(os.path.join(SHADERS_DIR, "*.fragmentshader"))
-VERSION = "3.2.3"
+VERSION = "3.3.0"
if os.path.exists('MANIFEST'):
os.remove('MANIFEST')
diff -r c07d1b4bd6563ba5f526372aacbac0ce99086923 -r 7edbfde96c3d55b227194394f46c0b2e6ed2b961 yt/__init__.py
--- a/yt/__init__.py
+++ b/yt/__init__.py
@@ -72,7 +72,7 @@
# The full license is in the file COPYING.txt, distributed with this software.
#-----------------------------------------------------------------------------
-__version__ = "3.2.3"
+__version__ = "3.3.0"
# First module imports
import numpy as np # For modern purposes
https://bitbucket.org/yt_analysis/yt/commits/8bbb84522183/
Changeset: 8bbb84522183
Branch: stable
User: ngoldbaum
Date: 2016-07-24 15:38:25+00:00
Summary: Added tag yt-3.3.0 for changeset 7edbfde96c3d
Affected #: 1 file
diff -r 7edbfde96c3d55b227194394f46c0b2e6ed2b961 -r 8bbb845221830bf04613506aee0b63f79d8bb656 .hgtags
--- a/.hgtags
+++ b/.hgtags
@@ -5193,3 +5193,4 @@
0000000000000000000000000000000000000000 yt-3.2.3
0000000000000000000000000000000000000000 yt-3.2.3
83d2c1e9313e7d83eb5b96888451ff2646fd8ff3 yt-3.2.3
+7edbfde96c3d55b227194394f46c0b2e6ed2b961 yt-3.3.0
Repository URL: https://bitbucket.org/yt_analysis/yt/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
More information about the yt-svn
mailing list