Joss-reviews: [REVIEW]: Geometric nested sampling

Created on 14 Oct 2019  ·  96Comments  ·  Source: openjournals/joss-reviews

Submitting author: @SuperKam91 (Kamran Javid)
Repository: https://github.com/SuperKam91/gns
Version: v1.01
Editor: @mbobra
Reviewer: @ziotom78, @zhampel
Archive: 10.5281/zenodo.3569956

Status

status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/34c9c9b4b15a502199f0b4c68ec7e48b"><img src="https://joss.theoj.org/papers/34c9c9b4b15a502199f0b4c68ec7e48b/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/34c9c9b4b15a502199f0b4c68ec7e48b/status.svg)](https://joss.theoj.org/papers/34c9c9b4b15a502199f0b4c68ec7e48b)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@ziotom78 & @zhampel, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

  1. Make sure you're logged in to your GitHub account
  2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @mbobra know.

✨ Please try and complete your review in the next two weeks ✨

Review checklist for @ziotom78

Conflict of interest

  • [x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

General checks

  • [x] Repository: Is the source code for this software available at the repository url?
  • [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • [x] Contribution and authorship: Has the submitting author (@SuperKam91) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

  • [x] Installation: Does installation proceed as outlined in the documentation?
  • [x] Functionality: Have the functional claims of the software been confirmed?
  • [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • [x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
  • [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

  • [x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
  • [x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
  • [x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @zhampel

Conflict of interest

  • [x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

General checks

  • [x] Repository: Is the source code for this software available at the repository url?
  • [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • [x] Contribution and authorship: Has the submitting author (@SuperKam91) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

  • [x] Installation: Does installation proceed as outlined in the documentation?
  • [x] Functionality: Have the functional claims of the software been confirmed?
  • [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • [x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
  • [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

  • [x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
  • [x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
  • [x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?
accepted published recommend-accept review
Source
picture whedon

All 96 comments

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @ziotom78, @zhampel it looks like you're currently assigned to review this paper :tada:.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

  1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

watching

  1. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

notifications

For a list of things I can do to help you, just type:

@whedon commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf
whedon picture whedon on 14 Oct 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 14 Oct 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 14 Oct 2019

👋@ziotom78 @zhampel Thank you again for volunteering to review. The review instructions are listed above. Please let me know if you have any questions!

mbobra picture mbobra on 14 Oct 2019

I am still completing the review of the code, but I started reading the paper as well. One thing I note is Fig. 2, which has two "X" marks that are explained neither in the caption nor in the text. The figure is obviously Fig. 3 in the arXiv paper 1905.09110; however, in the arXiv paper Fig. 3 makes sense because it is better explained and placed alongside Fig. 2. I believe that you should include the same figure and the same level of detail in this paper as well.

If the paper length is an issue, you could scale down Fig. 2 in the JOSS paper a bit: the information content is very small (a sphere, three points, and three labels), but the space it takes is really huge.

ziotom78 picture ziotom78 on 22 Oct 2019

@whedon generate pdf

SuperKam91 picture SuperKam91 on 22 Oct 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 22 Oct 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 22 Oct 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 22 Oct 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 22 Oct 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 22 Oct 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 22 Oct 2019

@SuperKam91 As I begin my review, can you please include comprehensive guidelines for contributing or reporting issues to your codebase? Here's an example.

zhampel picture zhampel on 22 Oct 2019

I am still completing the review of the code, but I started reading the paper as well. One thing I note is Fig. 2, which has two "X" marks that are explained neither in the caption nor in the text. The figure is obviously Fig. 3 in the arXiv paper 1905.09110; however, in the arXiv paper Fig. 3 makes sense because it is better explained and placed alongside Fig. 2. I believe that you should include the same figure and the same level of detail in this paper as well.

If the paper length is an issue, you could scale down Fig. 2 in the JOSS paper a bit: the information content is very small (a sphere, three points, and three labels), but the space it takes is really huge.

Hi @ziotom78 thank you for your comments on the paper. While I gave some information on the coordinate labels in the caption of Figure 2 (n.b. captions should be visible in the .pdfs generated in this thread, but probably not in the .md file itself), I have added a couple of sentences in the main text elaborating more on them, at end of the main body of text. With regards to the figure sizes, I have tried to reduce them using different syntaxes to the one suggested in the JOSS paper.md example. These worked in the .md files, but not in the .pdf generated here, and so I have had to revert back to the original sizing. It would be very useful if the JOSS template provided an example of how to scale images which is compatible with the pdf generation used here.

SuperKam91 picture SuperKam91 on 22 Oct 2019

Hi @zhampel , I have added a section explaining how to contribute to the project/ report issues at the bottom of the README of the repo.

SuperKam91 picture SuperKam91 on 23 Oct 2019

As issue #3 is now closed, I think that the paper and the package are ok, but let's wait for @zhampel's approval too. The functionality provided by the package looks good, nice work!

However, there are a few suggestions I would like to give to @SuperKam91 :

  • The API documentation is ok, but it is surely not «good» according to JOSS' guidelines:

    • It is just a list of functions provided by the package, with no example for any of them. Compare this with the documentation of the Python's standard library (e.g., the datetime module): short code snippet explain how each function is meant to be used.

    • As the list of functions provided by the package is very long, some text introducing each module (e.g., gns.keeton_calculations) would surely have helped interested readers. Again, Python's documentation is a good example to be used as reference.

  • The README is overly long, and it provides long textual descriptions of how to use the library, when short Python snippets would have provided the same information in a much clearer form.

  • The review process was quite long because there were trivial errors in the source code that should have been spotted by the author.

In the future, please read carefully Author and Reviewer Guides before submitting a paper to JOSS, as this will ensure a much faster and smoother review process.

ziotom78 picture ziotom78 on 6 Nov 2019
❤1

👋 @zhampel Let me know if you have any questions or need any help completing your review!

mbobra picture mbobra on 6 Nov 2019

@SuperKam91
I agree with @ziotom78 as well. Your submission's functionality is as advertised, but the documentation is lacking in detail. For example, while not explicitly required, function input types and descriptors provide users context for implementation. This is also reflected in the difficulty in scanning the example code in the README, which I would not characterize as a usage guide.

With respect to testing, it doesn't appear that the scripts in the test directory strictly qualify as unit tests, specifically the lack of assertion type tests. This would also be facilitated or at least clarified by care detailing of input argument types and type-checks as appropriate. This is also evident in abundant commented code ending with #debug or similar. For example on line 120 of nested_run.py:

#elif setupDict['sampler'] == 'MH' or setupDict['sampler'] == 'MH geom': #temporary whilst testing geometric ns

If such lines are intended for debugging or testing, then the preference would be to add in some testing capability or flags to ensure such tests are performed with requisite feedback.

Furthermore, I think the paper and docs still have some errors. Examples:

  • on page 3: "For example, parameters which... the trial distribution..."
    The sentence is not complete as 'For example' and 'the trial distribution' do not relate properly.
    You can simply state 'periodic properties' instead of 'circular or periodic'
  • In the 4th paragraph of the online docs: "Note for sampling spherical sampling, two physical parameters..."
  • You also use quotes frequently when they are not necessary.

I recommend that the written components of the submission be re-reviewed and corrected, as well as addressing the lack of clear comments as well as copious commented code within the main codebase. I also highly recommend use of a style guide for Python code such as pep8.

zhampel picture zhampel on 8 Nov 2019

@whedon generate pdf

SuperKam91 picture SuperKam91 on 8 Nov 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 8 Nov 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 8 Nov 2019

@SuperKam91
I agree with @ziotom78 as well. Your submission's functionality is as advertised, but the documentation is lacking in detail. For example, while not explicitly required, function input types and descriptors provide users context for implementation.

Hi @zhampel thank you for your comments. I will address them sequentially:

This is also reflected in the difficulty in scanning the example code in the README, which I would not characterize as a usage guide.

I'm not quite sure I follow unfortunately, are you saying the example needs more comments to explain what each line of code does? Anyway, I have added more documentation to the toy_models.py sub-package which is called from the example.

With respect to testing, it doesn't appear that the scripts in the test directory strictly qualify as unit tests, specifically the lack of assertion type tests.

While I didn't see anything in the JOSS guidelines specifying that unit tests were strictly necessary, I appreciate your point, and also acknowledge the fact that a lot of JOSS repos do include them, and therefore I have included some in tests.py. For a number of toy models, these essentially check that the statistics associated with the nested sampling runs are calculated correctly.

This is also evident in abundant commented code ending with #debug or similar. For example on line 120 of nested_run.py:

#elif setupDict['sampler'] == 'MH' or setupDict['sampler'] == 'MH geom': #temporary whilst testing geometric ns

If such lines are intended for debugging or testing, then the preference would be to add in some testing capability or flags to ensure such tests are performed with requisite feedback.

I have taken care of such redundant/commented out code.

Furthermore, I think the paper and docs still have some errors. Examples:

* on page 3: "For example, parameters which... the trial distribution..."
  The sentence is not complete as 'For example' and 'the trial distribution' do not relate properly.
  You can simply state 'periodic properties' instead of 'circular or periodic'

* In the 4th paragraph of the online docs: "Note for sampling spherical sampling, two physical parameters..."

I have addressed these two typos, thank you for pointing them out.

I recommend that the written components of the submission be re-reviewed and corrected, as well as addressing the lack of clear comments as well as copious commented code within the main codebase. I also highly recommend use of a style guide for Python code such as pep8.

I appreciate the code API may not be very good in certain places, but as I said to @ziotom78 in a closed issue, I have ensured that the API is far superior for all the sub-packages/functions which an end-user is typically going to interact with, i.e. the sub-packages:
nested_run.py
plotting.py
output.py
theoretical_funcs.py
toy_models.py
And the other most relevant functions/classes in other sub-packages

I have made the code pep8-compliant other than linebreaks in comments (see below comments)

On another note, I added an extra sentence to the paper explaining where the relative performances of GNS and another popular nested sampling algorithm, MultiNest, can be found (at the end of the section Bayesian inference and nested sampling).

SuperKam91 picture SuperKam91 on 8 Nov 2019

@SuperKam91 I pulled your most recent changes, but I would not agree with you statement that

I have taken care of such redundant/commented out code.

Looking again in nested_run.py, I still see a significant number of commented full lines with qualifications like 'temporary' and 'debug'.

It would be worth you intended users' time to clarify your code as much as possible.

zhampel picture zhampel on 9 Nov 2019

While I would love to re-write the package following pep8, I think it is unlikely I will get time to.

No need to rewrite your package, there are automatic tools like autopep8, yapf and black that can do the job for you.

ziotom78 picture ziotom78 on 9 Nov 2019

Thank you for you reply @zhampel, that seems very strange. Did you pull from PyPi? I haven't added any of the the review-changes to that version of the package yet, as I figured I would do it at the end of the review process (to avoid having to keep releasing new versions). Please use the version in the github repo for now.
If not I can only think that you looked between me posting the above comment and me uploading the changes (though I'm sure they were almost synchronous), but they are definitely present in the repo now.

@ziotom78 thank you for the heads up, those are truly great packages! Consider my code now almost fully PEP8 compliant- the only places where it isn't is for lines which include comments, which the packages cannot linebreak. I ran the pycodestyle test and got the following output:
1106 E501 line too long (96 > 79 characters)
Hopefully you will spare me the pain of line breaking my 1106 lines of comments!

SuperKam91 picture SuperKam91 on 9 Nov 2019

@SuperKam91 There are tools like autopep8 that will automatically format your code for you so you don't have to do anything by hand :)

mbobra picture mbobra on 14 Nov 2019

@SuperKam91 There are tools like autopep8 that will automatically format your code for you so you don't have to do anything by hand :)

Hi @mbobra as I mentioned above, I have already used tools including ‘autopep8’, ‘black’ and ’yapf’ to arrive at the current state. It is fully pep8 compliant apart from my comment lines being over the 80 characters per line limit, and also my doc strings being over the limit. Understandably, the tools cannot correctly break all the commented lines, especially lines which have comments proceeding code. But since these are just comments I don’t think it should do much harm.

SuperKam91 picture SuperKam91 on 19 Nov 2019

Hi @mbobra @zhampel any updates on this? Please see my above posts which I hope address your comments to a satisfactory level.
In particular I think I have satisfied the following points at the following levels, according to the JOSS review criteria:

  • API documentation:
    OK: Core API functionality is documented
  • Tests:
    Good: An automated test suite hooked up to an external service such as Travis-CI or similar
    For this one the main (unit) tests to ensure correct functionality can be run by running tests/tests.py
SuperKam91 picture SuperKam91 on 28 Nov 2019

@zhampel Does this submission pass your review? If so, can you please approve this for publication (tick all the checkboxes) or let @SuperKam91 know what issues still remain?

mbobra picture mbobra on 2 Dec 2019

@zhampel Please let me know if you need any help assessing whether this submission passes review! I am happy to help.

mbobra picture mbobra on 9 Dec 2019

@SuperKam91

I apologize for my delay in coming back to your submission.

Thanks for addressing most of the issues. However, I still feel like leaving extremely long comments in code sets a negative precedent for JOSS accepted submissions. You wrote the following:

But since these are just comments I don’t think it should do much harm.

yet, I see this massive single line (327) in tests/test.py:

setupDict = {'verbose': True, 'trapezoidalFlag': False, 'ZLiveType':'average X', terminationType':'evidence', 'terminationFactor': 0.01, 'sampler': None, 'outputFile': None, 'space':'linear', 'paramGeomList':None}

among others. While I agree that long docstrings do not do much harm, I argue that if you want your novel code to be useful to others, with which a publication through JOSS facilitates and which provides authors official credit, then it's best to abide by coding conventions. They are there for a reason, to be helpful for others. And that's why there are automated tools to implement those conventions.

@mbobra
I have reluctantly checked all the boxes and added an issue ticket for the long lines (a more appropriate documentation for this discussion). The state of this codebase is not up to my standards but it is within the guidelines for publication. I would like to stress that reviewers volunteer their time for submissions, and if authors do not take reviewers' time and experience into consideration, then I think it also sets a poor precedent for acceptance. This can affect not just the reviewing process, but more importantly the end-users in the open-source community which we serve.

zhampel picture zhampel on 9 Dec 2019
👍1

@zhampel Thank you for your time and your well-considered review. I totally and completely understand your comments. We at JOSS are trying to strike some kind of reasonable balance between incentivizing people to write open source software (with a reasonable amount of time and effort) and adhering to the most ideal coding standards. I personally agree with you that long comments don't adhere to coding conventions, but I'm also bound (like you) to follow JOSS' guidelines. I hope you feel positive about your experience reviewing for JOSS. And if you feel like the JOSS guidelines should be modified, please open an issue! Thank you sincerely for your time and effort ☀️

mbobra picture mbobra on 10 Dec 2019
👍1

@SuperKam91 We're almost there! Can you please archive your release on Zenodo to obtain a DOI and then put that in your README.md file? After that I think we're done 🎉

mbobra picture mbobra on 10 Dec 2019

@SuperKam91

I apologize for my delay in coming back to your submission.

Thanks for addressing most of the issues. However, I still feel like leaving extremely long comments in code sets a negative precedent for JOSS accepted submissions. You wrote the following:

But since these are just comments I don’t think it should do much harm.

yet, I see this massive single line (327) in tests/test.py:

setupDict = {'verbose': True, 'trapezoidalFlag': False, 'ZLiveType':'average X', terminationType':'evidence', 'terminationFactor': 0.01, 'sampler': None, 'outputFile': None, 'space':'linear', 'paramGeomList':None}

among others. While I agree that long docstrings do not do much harm, I argue that if you want your novel code to be useful to others, with which a publication through JOSS facilitates and which provides authors official credit, then it's best to abide by coding conventions. They are there for a reason, to be helpful for others. And that's why there are automated tools to implement those conventions.

@mbobra
I have reluctantly checked all the boxes and added an issue ticket for the long lines (a more appropriate documentation for this discussion). The state of this codebase is not up to my standards but it is within the guidelines for publication. I would like to stress that reviewers volunteer their time for submissions, and if authors do not take reviewers' time and experience into consideration, then I think it also sets a poor precedent for acceptance. This can affect not just the reviewing process, but more importantly the end-users in the open-source community which we serve.

Hi @zhampel I will ensure down the road that the code is full pep8 compliant (including comment/docstring lines), even if I do this process gradually, rather than all at once.

Thanks again for taking the time to do the review. Also thank you to @ziotom78 for his review, and to @mbobra for overseeing everything.

SuperKam91 picture SuperKam91 on 10 Dec 2019

@SuperKam91 I appreciate your effort; I think pep8 compliance would make the code much more legible. Could you please archive your release on Zenodo to obtain a DOI and then put that in your README.md file? Please make sure the title and author list of the Zenodo entry match the title and author list of the JOSS paper. Thank you!

mbobra picture mbobra on 10 Dec 2019

@SuperKam91 I appreciate your effort; I think pep8 compliance would make the code much more legible. Could you please archive your release on Zenodo to obtain a DOI and then put that in your README.md file? Please make sure the title and author list of the Zenodo entry match the title and author list of the JOSS paper. Thank you!

Done!

SuperKam91 picture SuperKam91 on 10 Dec 2019

@whedon generate pdf

mbobra picture mbobra on 11 Dec 2019 
Attempting PDF compilation. Reticulating splines etc...
whedon picture whedon on 11 Dec 2019

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 11 Dec 2019

@whedon check references

mbobra picture mbobra on 11 Dec 2019 
Attempting to check references...
whedon picture whedon on 11 Dec 2019

```Reference check summary:

OK DOIs

  • None

MISSING DOIs

INVALID DOIs

  • None
    ```
whedon picture whedon on 11 Dec 2019

@SuperKam91 Could you please include DOIs for all your references? So for example, the first entry in paper.bib would look like this: 

@article{chib1995understanding,
  title={Understanding the metropolis-hastings algorithm},
  author={Chib, Siddhartha and Greenberg, Edward},
  journal={The american statistician},
  volume={49},
  number={4},
  pages={327--335},
  year={1995},
  publisher={Taylor \& Francis Group},
  doi={10.1080/00031305.1995.10476177}
}

Thank you 😄

mbobra picture mbobra on 11 Dec 2019

@whedon check references

mbobra picture mbobra on 7 Jan 2020 
Attempting to check references...
whedon picture whedon on 7 Jan 2020

Hi @mbobra apologies for the delay in including the reference DOIs. I am basically waiting on my university to provide me with a DOI for one of the cited papers, but they are taking an age to do so. As soon as they provide it I will update and the references should be good to go!

SuperKam91 picture SuperKam91 on 7 Jan 2020
👍1

@SuperKam91 Do you want to go ahead and publish the paper without the DOI for that one citation? That's fine with me -- we don't need to hold up your publication just for that singular DOI.

mbobra picture mbobra on 24 Jan 2020

@whedon check references

SuperKam91 picture SuperKam91 on 25 Jan 2020

Hi @mbobra in the end I've lost patience with regard to my university providing me the DOI of the reference, so I just created one for it myself using Zenodo. Hopefully this is sufficient, in which case we can proceed.

SuperKam91 picture SuperKam91 on 25 Jan 2020
👍1

@whedon generate pdf

SuperKam91 picture SuperKam91 on 25 Jan 2020

PDF failed to compile for issue #1809 with the following error:

Error reading bibliography ./paper.bib (line 10, column 3):
unexpected "d"
expecting space, ",", white space or "}"
Error running filter pandoc-citeproc:
Filter returned error status 1
Looks like we failed to compile the PDF

whedon picture whedon on 25 Jan 2020

@whedon check references

SuperKam91 picture SuperKam91 on 25 Jan 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- None
whedon picture whedon on 25 Jan 2020

@whedon generate pdf

SuperKam91 picture SuperKam91 on 25 Jan 2020

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 25 Jan 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- None
whedon picture whedon on 25 Jan 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- None
whedon picture whedon on 27 Jan 2020

@whedon set 10.5281/zenodo.3569956 as archive

mbobra picture mbobra on 27 Jan 2020

OK. 10.5281/zenodo.3569956 is the archive.

whedon picture whedon on 27 Jan 2020

@whedon set v1.01 as version

mbobra picture mbobra on 27 Jan 2020

OK. v1.01 is the version.

whedon picture whedon on 27 Jan 2020

@openjournals/joss-eics the paper is ready for final processing

mbobra picture mbobra on 27 Jan 2020
👍1

@SuperKam91 I am the AEiC helping to process this submission. Below are some remaining minor points to work on in relation to your paper.

  • [x] The first sentence is quite difficult to read. Can you consider rephrasing, splitting into multiple sentences, or adding more comma's?
  • [x] Please change ...present here is a based on... to ...present here is based on...
  • [x] Fix typo in intutive which should be intuitive
  • [x] Fix typo in equivlance equivalance
  • [x] Consider changing Figures 6 - 9 of the paper.... to Figures 6 - 9 of that paper.... which to me makes it a bit clearer that you are referring to the before mentioned study not the current paper.
  • [x] Please add comma in To prevent this one must sample a large number... i.e. To prevent this, one must sample a large number...
  • [x] Should This solution can be problematic if... be rephrased to Obtaining this solution can be problematic if...?
  • [x] Can you replace ...is ‘wrapped’ around... with ...is "wrapped" around..., so double quotation symbols are used consistently throughout the text?
  • [x] Please spell out United Kingdom in your affiliations.
  • [x] This paper is about to be processed for acceptance in JOSS. I recommend you also proofread the text thoroughly one last time.
Kevin-Mattheus-Moerman picture Kevin-Mattheus-Moerman on 29 Jan 2020
👍1

Hi @Kevin-Mattheus-Moerman, I can confirm I have addressed the changes proposed above. Furthermore I have given the paper a final proofread.

SuperKam91 picture SuperKam91 on 30 Jan 2020

@whedon generate pdf

SuperKam91 picture SuperKam91 on 30 Jan 2020

PDF failed to compile for issue #1809 with the following error:

/app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:377:in parse': (tmp/1809/paper.md): did not find expected key while parsing a block mapping at line 2 column 1 (Psych::SyntaxError) from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:377:inparse_stream'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:325:in parse' from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:252:inload'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:473:in block in load_file' from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:472:inopen'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:472:in load_file' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon.rb:125:inload_yaml'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon.rb:85:in initialize' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon/processor.rb:36:innew'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon/processor.rb:36:in set_paper' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/bin/whedon:55:inprepare'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:ininvoke_command'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/base.rb:466:instart'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/bin/whedon:116:in <top (required)>' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:inload'
from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in `

'

whedon picture whedon on 30 Jan 2020

@whedon check references

SuperKam91 picture SuperKam91 on 30 Jan 2020

@whedon generate pdf

Kevin-Mattheus-Moerman picture Kevin-Mattheus-Moerman on 30 Jan 2020

PDF failed to compile for issue #1809 with the following error:

/app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:377:in parse': (tmp/1809/paper.md): did not find expected key while parsing a block mapping at line 2 column 1 (Psych::SyntaxError) from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:377:inparse_stream'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:325:in parse' from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:252:inload'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:473:in block in load_file' from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:472:inopen'
from /app/vendor/ruby-2.4.4/lib/ruby/2.4.0/psych.rb:472:in load_file' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon.rb:125:inload_yaml'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon.rb:85:in initialize' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon/processor.rb:36:innew'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/lib/whedon/processor.rb:36:in set_paper' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/bin/whedon:55:inprepare'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/command.rb:27:in run' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:ininvoke_command'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor.rb:387:in dispatch' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/base.rb:466:instart'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-9847f98e9ec6/bin/whedon:116:in <top (required)>' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:inload'
from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in `

'

whedon picture whedon on 30 Jan 2020

@SuperKam91 did you have the ` symbols in the title field for the YAML content at the top of your paper there before? 

title: 'Geometric nested sampling: sampling from distributions defined on non-trivial geometries'

Perhaps change it to the following and try again:

title: Geometric nested sampling: sampling from distributions defined on non-trivial geometries
Kevin-Mattheus-Moerman picture Kevin-Mattheus-Moerman on 30 Jan 2020

@SuperKam91 - this PR will fix your paper compilation: https://github.com/SuperKam91/gns/pull/6

arfon picture arfon on 30 Jan 2020
👍1

@SuperKam91 - this PR will fix your paper compilation: SuperKam91/gns#6

So sorry about that @arfon, don't know how that occurred!

SuperKam91 picture SuperKam91 on 30 Jan 2020

@whedon generate pdf

SuperKam91 picture SuperKam91 on 30 Jan 2020

:point_right: Check article proof :page_facing_up: :point_left:

whedon picture whedon on 30 Jan 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- None
whedon picture whedon on 31 Jan 2020

@SuperKam91 thanks for making those changes. Looks like we are all set now.

Kevin-Mattheus-Moerman picture Kevin-Mattheus-Moerman on 1 Feb 2020

@whedon accept

Kevin-Mattheus-Moerman picture Kevin-Mattheus-Moerman on 1 Feb 2020 
Attempting dry run of processing paper acceptance...
whedon picture whedon on 1 Feb 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- None
whedon picture whedon on 1 Feb 2020

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/1261

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/1261, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

whedon picture whedon on 1 Feb 2020

@whedon accept deposit=true

Kevin-Mattheus-Moerman picture Kevin-Mattheus-Moerman on 1 Feb 2020 
Doing it live! Attempting automated processing of paper acceptance...
whedon picture whedon on 1 Feb 2020

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

whedon picture whedon on 1 Feb 2020

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

  1. Check final PDF and Crossref metadata that was deposited :point_right: https://github.com/openjournals/joss-papers/pull/1262
  2. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.01809
  3. If everything looks good, then close this review issue.

  4. Party like you just published a paper! 🎉🌈🦄💃👻🤘

    Any issues? notify your editorial technical team...

whedon picture whedon on 1 Feb 2020

:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.01809/status.svg)](https://doi.org/10.21105/joss.01809)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.01809">
  <img src="https://joss.theoj.org/papers/10.21105/joss.01809/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.01809/status.svg
   :target: https://doi.org/10.21105/joss.01809

This is how it will look in your documentation:

DOI

We need your help!

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

whedon picture whedon on 1 Feb 2020

Many thanks all for your help, I have made a small donation to JOSS in the hope that you all can keep up the good work in the future.

I have noticed a small typo in the references of the paper. Is it possible to update the publication now I have ratified it?

If not absolutely no worries, I will just include it in the arXiv version instead.

SuperKam91 picture SuperKam91 on 4 Feb 2020

@whedon check references

SuperKam91 picture SuperKam91 on 4 Feb 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- https://doi.org/10.1093/mnras/stz2341 is INVALID because of 'https://doi.org/' prefix
whedon picture whedon on 4 Feb 2020

@whedon check references

SuperKam91 picture SuperKam91 on 4 Feb 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- https://doi.org/10.1093/mnras/stz2341 is INVALID because of 'https://doi.org/' prefix
whedon picture whedon on 4 Feb 2020

Many thanks all for your help, I have made a small donation to JOSS in the hope that you all can keep up the good work in the future.

❤️ Many thanks!

I have noticed a small typo in the references of the paper. Is it possible to update the publication now I have ratified it?

Yes, please go ahead and make the fix in the master branch of your repository and mention me here (@arfon) when you've done this.

arfon picture arfon on 4 Feb 2020

@whedon check references

SuperKam91 picture SuperKam91 on 5 Feb 2020 
Reference check summary:

OK DOIs

- 10.1080/00031305.1995.10476177 is OK
- 10.1093/mnras/sty3115 is OK
- 10.17863/CAM.38865 is OK
- 10.1093/mnras/stz826 is OK
- 10.5281/zenodo.3627542 is OK
- 10.17863/CAM.40616 is OK
- 10.1093/mnras/stz2341 is OK
- 10.1111/j.1365-2966.2009.15247.x is OK
- 10.1111/j.1365-2966.2009.14548.x is OK
- 10.1214/06-BA127 is OK
- 10.1093/mnras/stv1911 is OK
- 10.1093/mnrasl/slv047 is OK
- 10.1111/j.1365-2966.2007.12353.x is OK
- 10.1093/mnras/sty074 is OK

MISSING DOIs

- None

INVALID DOIs

- https://doi.org/10.1093/mnras/stz2341 is INVALID because of 'https://doi.org/' prefix
whedon picture whedon on 5 Feb 2020

Many thanks all for your help, I have made a small donation to JOSS in the hope that you all can keep up the good work in the future.

Many thanks!

I have noticed a small typo in the references of the paper. Is it possible to update the publication now I have ratified it?

Yes, please go ahead and make the fix in the master branch of your repository and mention me here (@arfon) when you've done this.

Hi @arfon that's great, thank you so much. I have made the changes to master branch so we should be good to go. However, when "checking references" above it seems to have cached an old commit (perhaps I didn't wait long enough but I don't think this is usually an issue) which doesn't include the fix, so let me know if you have any problems with this.

SuperKam91 picture SuperKam91 on 5 Feb 2020

OK, this should be fixed now. The PDF might take a few hours to show up as fixed online due to caching.

Also, I think you're right, there's some kind of caching issue with Whedon too that I need to look into.

arfon picture arfon on 5 Feb 2020
👍1

@arfon I've been having troubles with this too, like in #1656. I'll check it soon and it's probably now worked out but it gets confusing!

kthyng picture kthyng on 5 Feb 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

whedon picture whedon  ·  12Comments
whedon picture whedon  ·  12Comments
whedon picture whedon  ·  6Comments
whedon picture whedon  ·  9Comments
whedon picture whedon  ·  13Comments