I think these two pull requests from Corentin are either good to go or
practically there, they just needs a couple more eyes on them.
We don't have a lot of Ramses experience among the people who commonly
review code so I understand why there's some reluctance. That said, I don't
think you need Ramses experience to understand what's going on.
If you have a chance to look these over, I'd appreciate it.
I am working on a new yt frontend for the Enzo-P code. Enzo-P outputs
runtime parameters in a libconfig format and I am looking for a reliable
package to read this.
yt has a libconfig-style reader in yt/utilities/pyparselibconfig, but it
does not seem to parse Enzo-P parameter files correctly. I have tried a
few other python libconfig parsers that do parse them correctly, so I
believe the problem is with the yt module. For what it's worth, the only
use of yt's libconfig parser is in the Enzo frontend for a certain style of
Enzo-3.0 data, but it doesn't look like this is being tested, nor do we
host any sample data of this format.
I have a PR open for the Enzo-P frontend here
<https://github.com/yt-project/yt/pull/1490> that makes use of an external
package, called libconf <https://pypi.python.org/pypi/libconf>. I've
implemented this as an on-demand import, so it will only be required if
you're actually loading Enzo-P data.
The pros for libconf are that it's pure python, pip installable, has a
permissive MIT license, and works in both python 2 and 3. The con is of
course that this adds a new dependency. Personally, I would prefer not
having to maintain our own module to do this, but I'm open to other
What are people's thoughts on adding this dependency?
Dear yt developers,
As part of an NSF software award, we are planning to perform a study on
Software Engineering Practices for Computational Science and Engineering
(CSE) software development. The discipline of software engineering focuses
on developing techniques and tools to assist developers in efficiently
building high-quality and trustworthy software. Code review is one of the
important techniques of software engineering defined as a systematic
examination of computer source code which intends to find and remove
vulnerabilities in the initial development phase and improve software
quality. Our plan is to understand the practices, impacts and barriers of
code review technique in CSE software development. For this study, we are
considering the Einstein Toolkit, yt-project and Brown Dog projects as use
You are invited to participate in this research project because you are a
developer of the yt project. Your participation in this research study is
voluntary. You may choose not to participate. If you decide to participate
in this research survey, you may withdraw at any time. If you decide not to
participate in this study or if you withdraw from participating at any
time, you will not be penalized.
The procedure involves filling an online survey that will take
approximately 20 minutes. Your responses will be kept confidential, and we
do not collect identifying information such as your name, email address, or
IP address. The survey questions will be about how you review code, how
your code is being reviewed, what are the impacts and expectations, if
there are any challenges or barriers, and potential areas of improvement.
We will do our best to keep your information confidential. All data is
stored in an electronic format. To help protect your confidentiality, the
survey will not contain information that will personally identify you. The
results of this study will be used for scholarly purposes only, and may be
shared with related project personnel.
If you have any questions about the research study, please contact
Gabrielle Allen (gdallen(a)illinois.edu), Roland Haas (rhaas(a)illinois.edu),
Nasir Eisty (neisty(a)crimson.ua.edu), Jeffrey Carver (carver(a)cs.ua.edu),
Daniel S. Katz (dskatz(a)illinois.edu).
This research has been reviewed according to University of Illinois at
Urbana-Champaign IRB procedures for research involving human subjects. If
you have any questions about your rights as a participant in this study or
any concerns or complaints, please contact the University of Illinois
Office for the Protection of Research Subjects at 217-333-2670
<(217)%20333-2670> or via email at irb(a)illinois.edu.
*Please click on the Survey Link
begin the survey. Please complete the survey by the end of Sunday,
September 17, 2017.*
Thank you very much!
- - - - - - - - - - - - - - - - - - - - - - - - -
Nasir Uddin Eisty
*Department of Computer Science*
*University of Alabama*
*Tuscaloosa, Alabama, USA*
I hope everyone's semester if starting off well.
I'd like to nominate Corentin Cadiou (@cphyc on github) as a yt project
member. Corentin has been regularly contributing for almost a year now,
sending in high-quality contributions, including bugfixes and improvements
for RAMSES and other octree AMR data. I'd like to recognize his
contributions up until now and empower further contributions by nominating
him as a yt project member.
According to YTEP-1776 (
http://ytep.readthedocs.io/en/latest/YTEPs/YTEP-1776.html), we need
positive votes from three additional yt project members to accept the
Once that happens I will update the website and the YTEP and add Corentin
to the yt org on github. Corentin, once that happens please feel free to
add a short bio on the website under the project members page.
Hi Ole & All,
Sorry I missed your earlier email, I moved to Germany this summer and
getting things settled had me very busy for the last few months. I've been
building the debian package on my workstation at my former university, I'm
going to move it to a VPS I've set up and try automating the build process
a bit more so that it won't rely on my free time quite as much. I'm going
to try and fix these bugs this week, I'll update you Friday about what I'm
able to get done. Thanks for the patience!
On Tue, Sep 12, 2017 at 8:24 AM, Ole Streicher <olebole(a)debian.org> wrote:
> Dear yt developers,
> as you may know, yt has an official Debian package, and is delivered
> with our current stable version:
> The current version, however, needs some love: we don't have the newest
> version; the current one (3.3.3) fails to build with the current Cython
> version, and it does not build anymore on many of our platforms. It has
> now three release critical bugs:
> I already tried to contact Ben for this, but did not get a response. The
> package seems to be popular, and it is used by a number of people, so it
> would be great if we could bring it back into a good shape.
> Best regards