Hi all, 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 opinions. What are people's thoughts on adding this dependency? Britton
I'm okay with this. I thought Enzo-P used a non-libconfig style (something about equations outside of quotation marks) but it sounds like that's no longer accurate. On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote:
Hi all,
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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I looked over libconf and it seems like a good library that I don't mind having as an optional dependency for yt. In particular, it's: * Reasonably up-to-date and maintained (last release early this year) * Pure python, supporting python 2 and 3, with a universal wheel available on pypi * Permissively licensed. While it would be nice if we could do this without adding a new dependency, if pyparselibconfig isn't sufficient, and Britton doesn't want to work on fixing it, I think the suggested approach is fine (unless someone steps up to fix pyparselibconfig). If we do decide to go this route, I'd prefer it if we remove pyparselibconfig and drop support in the Enzo frontend for libconfig parameter files in enzo-3.0. In the real world, I don't think many (any?) datasets were produced using that format, since the PR adding support for it was never merged, and I'd prefer we don't have known-buggy code in the codebase to trip up any possible future users. On Mon, Sep 18, 2017 at 3:38 PM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi all,
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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Matt, you are also correct. Enzo-P ingests a non-libconfig style format, but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch. On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm okay with this.
I thought Enzo-P used a non-libconfig style (something about equations outside of quotation marks) but it sounds like that's no longer accurate.
On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote:
Hi all,
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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because the other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If there was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work. Cheers, Sam On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith <brittonsmith@gmail.com> wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style format, but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm okay with this.
I thought Enzo-P used a non-libconfig style (something about equations outside of quotation marks) but it sounds like that's no longer accurate.
On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote:
Hi all,
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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Ooh, I change my vote to exploring this option first. On Mon, Sep 18, 2017 at 7:03 PM, Sam Skillman <samskillman@gmail.com> wrote:
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because the other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If there was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work.
Cheers, Sam
On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith <brittonsmith@gmail.com> wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style format, but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm okay with this.
I thought Enzo-P used a non-libconfig style (something about equations outside of quotation marks) but it sounds like that's no longer accurate.
On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote:
Hi all,
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 that makes use of an external package, called 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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Oh, now I see that this was just a ploy to get me to contribute again! Just when you think you're out.... But seriously, happy to help if desired, but also happy to not get in the way and delay getting things done. Hope you all are doing well. On Mon, Sep 18, 2017 at 6:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Ooh, I change my vote to exploring this option first.
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because
other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If there was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work.
Cheers, Sam
On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith <brittonsmith@gmail.com> wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style
but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm okay with this.
I thought Enzo-P used a non-libconfig style (something about equations outside of quotation marks) but it sounds like that's no longer
accurate.
On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com>
wrote:
Hi all,
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
On Mon, Sep 18, 2017 at 7:03 PM, Sam Skillman <samskillman@gmail.com> wrote: the format, 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 that makes use of an external package, called 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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
libconf, while being significantly more complicated than pyparselibconfig, seems also far superior. +1 from me for jettisoning pyparselibconfig. On Mon, Sep 18, 2017 at 6:21 PM, Sam Skillman <samskillman@gmail.com> wrote:
Oh, now I see that this was just a ploy to get me to contribute again! Just when you think you're out....
But seriously, happy to help if desired, but also happy to not get in the way and delay getting things done. Hope you all are doing well.
On Mon, Sep 18, 2017 at 6:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Ooh, I change my vote to exploring this option first.
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because
other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If
was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work.
Cheers, Sam
On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith <brittonsmith@gmail.com> wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style
but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm okay with this.
I thought Enzo-P used a non-libconfig style (something about equations outside of quotation marks) but it sounds like that's no longer
accurate.
On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com>
wrote:
Hi all,
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
On Mon, Sep 18, 2017 at 7:03 PM, Sam Skillman <samskillman@gmail.com> wrote: the there format, 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 that makes use of an external package, called 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 opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Matt, you're now officially the Ferdinand Magellan of the exploration. Let us know how it goes. On Mon, Sep 18, 2017, 7:47 PM Sam Skillman <samskillman@gmail.com> wrote:
libconf, while being significantly more complicated than pyparselibconfig, seems also far superior. +1 from me for jettisoning pyparselibconfig.
On Mon, Sep 18, 2017 at 6:21 PM, Sam Skillman <samskillman@gmail.com> wrote:
Oh, now I see that this was just a ploy to get me to contribute again! Just when you think you're out....
But seriously, happy to help if desired, but also happy to not get in the way and delay getting things done. Hope you all are doing well.
On Mon, Sep 18, 2017 at 6:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Ooh, I change my vote to exploring this option first.
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because the other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If
was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work.
Cheers, Sam
On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith <brittonsmith@gmail.com
wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style
but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I'm okay with this.
I thought Enzo-P used a non-libconfig style (something about
equations
outside of quotation marks) but it sounds like that's no longer accurate.
On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote: > > Hi all, > > 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
On Mon, Sep 18, 2017 at 7:03 PM, Sam Skillman <samskillman@gmail.com> wrote: there format, 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 that makes use of an > external package, called 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 > opinions. > > What are people's thoughts on adding this dependency? > > Britton > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hahahahhaha... On Mon, Sep 18, 2017 at 8:36 PM, Britton Smith <brittonsmith@gmail.com> wrote:
Matt, you're now officially the Ferdinand Magellan of the exploration. Let us know how it goes.
On Mon, Sep 18, 2017, 7:47 PM Sam Skillman <samskillman@gmail.com> wrote:
libconf, while being significantly more complicated than pyparselibconfig, seems also far superior. +1 from me for jettisoning pyparselibconfig.
On Mon, Sep 18, 2017 at 6:21 PM, Sam Skillman <samskillman@gmail.com> wrote:
Oh, now I see that this was just a ploy to get me to contribute again! Just when you think you're out....
But seriously, happy to help if desired, but also happy to not get in the way and delay getting things done. Hope you all are doing well.
On Mon, Sep 18, 2017 at 6:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Ooh, I change my vote to exploring this option first.
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because the other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If
was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work.
Cheers, Sam
On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith < brittonsmith@gmail.com> wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style
but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com
wrote: > > I'm okay with this. > > I thought Enzo-P used a non-libconfig style (something about equations > outside of quotation marks) but it sounds like that's no longer accurate. > > On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote: >> >> Hi all, >> >> 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
>> 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 that makes use of an >> external package, called 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
On Mon, Sep 18, 2017 at 7:03 PM, Sam Skillman <samskillman@gmail.com> wrote: there format, tried a few prefer not
>> having to maintain our own module to do this, but I'm open to other >> opinions. >> >> What are people's thoughts on adding this dependency? >> >> Britton >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
Uh, I call my exploration to a halt! (Geez Sam, talk about a bait-n-switch :) On Sep 18, 2017 10:36 PM, "Britton Smith" <brittonsmith@gmail.com> wrote:
Matt, you're now officially the Ferdinand Magellan of the exploration. Let us know how it goes.
On Mon, Sep 18, 2017, 7:47 PM Sam Skillman <samskillman@gmail.com> wrote:
libconf, while being significantly more complicated than pyparselibconfig, seems also far superior. +1 from me for jettisoning pyparselibconfig.
On Mon, Sep 18, 2017 at 6:21 PM, Sam Skillman <samskillman@gmail.com> wrote:
Oh, now I see that this was just a ploy to get me to contribute again! Just when you think you're out....
But seriously, happy to help if desired, but also happy to not get in the way and delay getting things done. Hope you all are doing well.
On Mon, Sep 18, 2017 at 6:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Ooh, I change my vote to exploring this option first.
As the original author of pyparselibconfig, I release all obligations of keeping it around. I have a *very* vague memory that I wrote it because the other options at the time were either painful to install, bloated, or possibly both. My guess is that it worked for some file associated with Enzo-3, which may or may not have been libconf feature complete. If
was still interest in supporting pyparselibconfig, I'd be open to taking an example cfg file and fumbling around a bit to see if I can get it to work.
Cheers, Sam
On Mon, Sep 18, 2017 at 2:48 PM, Britton Smith < brittonsmith@gmail.com> wrote:
Matt, you are also correct. Enzo-P ingests a non-libconfig style
but outputs in both this native format and normal libconfig. It would also be great to be able to parse the native format, but that would need to be written from scratch.
On Mon, Sep 18, 2017 at 1:43 PM, Matthew Turk <matthewturk@gmail.com
wrote: > > I'm okay with this. > > I thought Enzo-P used a non-libconfig style (something about equations > outside of quotation marks) but it sounds like that's no longer accurate. > > On Sep 18, 2017 3:38 PM, "Britton Smith" <brittonsmith@gmail.com> wrote: >> >> Hi all, >> >> 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
>> 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 that makes use of an >> external package, called 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
On Mon, Sep 18, 2017 at 7:03 PM, Sam Skillman <samskillman@gmail.com> wrote: there format, tried a few prefer not
>> having to maintain our own module to do this, but I'm open to other >> opinions. >> >> What are people's thoughts on adding this dependency? >> >> Britton >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (5)
-
Britton Smith -
Cameron Hummels -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman