Skip to content

Conversation

@matteomoscheni
Copy link

As I have mentioned in our latest Skype call, I hereby submit a pull request with the modified vtk.py file.

Please notice that it would be nice if you could merge it with the existing one for the import of the 2.0 version. In this way, one can import either a 2.0 or a 4.2 version without bothering about which function to choose.

Lack of "sanity check" commands (e.g. assert, error display, exc.)

From line 154 you will find some suggested modifications to export_vtk. Given the absence of any reference file, I have no idea how to correctly structure the exported file.

Lack of "sanity check" commands (e.g. assert, error display, exc.)
From line 154 suggest modifications which do not work yet.
@mattngc
Copy link
Member

mattngc commented Sep 19, 2019

Hey @matteomoscheni, thanks for submitting this contribution.

Unfortunately this code isn't ready for merging. Here are a few observations:

  • As you can see, the automated test build is failing. It looks like you have been using mixed tabs and spaces in your editor. Raysect always uses the PEP8 python standards which means using 4 spaces.
  • Its great that you have tried to add support for VTK 4.x, but unfortunately this has been implemented by breaking support for VTK 2.x files. A better approach would be to detect the version type around lines 93-97 and then send the code along different paths based on the version. This would allow future customisation as more versions appear and are supported.
  • Also, I notice you have based your development off master. Usually its better to base off a private branch off 'development'. Otherwise your local branches could end up getting very messy or even broken when you try to pull updates from our version of the code. The system we use is known as 'git flow'. I recommend reading the tutorial here.
    https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

@CnlPepper may have some more comments. I think we should probably make these fixes in a new branch. So it would be better if you can read up on git flow before we proceed.

@matteomoscheni
Copy link
Author

Thank you @mattngc for the advices and I apologize for the indentation errors. It would be great to have a "unified" script able to distinguish between 2.0 and 4.2 version!

@CnlPepper
Copy link
Member

Is this still being worked on or can I close it as a stale PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants