Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] feature/python_module : Adding libpointmatcher's Python bindings (#222) #397

Merged
merged 32 commits into from Nov 2, 2020

Conversation

aguenette
Copy link
Member

@aguenette aguenette commented Aug 6, 2020

Here are the python's bindings for libpointmatcher as requested in the issue #222.

Things to do before merging :

  • Make sure that the module get installed in the sites-packages of the current Python environment (maybe using pip install?).

  • Provide a tutorial on how to compile and install the module.

  • Provide a tutorial on how to use it.

  • Finish to transpose the C++ examples into Python.

  • Merging PR Replaced the remaining raw pointers with shared pointers in Registrar.h #395

  • Make sure that the bindings compile on macOS?

Testing :

If you want to test the Python module on your side, clone my libpointmatcher's fork. Then, follow the compilation and installation instructions from this tutorial.

I've tested it with g++ 7.5.0 and clang++ 10.0.0 on Ubuntu 18.04.

Edit: The bindings no longer compiles on clang++ 10.0, and on clang++ 6.0 either, since the adding of the IO module.

Feedback on the bindings themselves and the tutorials will be really appreciated, thanks! 🙂

Last edited : 20 august 2020

@aguenette aguenette requested a review from pomerlef August 6, 2020 21:06
@aguenette aguenette changed the title [WIP] feature/python_module : Adding libpointmatcher's Python bindings [WIP] feature/python_module : Adding libpointmatcher's Python bindings (#222) Aug 7, 2020
The python module now only link with pointmatcher instead of building it.
The python module can now be installed.
Also fixed a typo in the IO.cpp file
Removed the bindings for ParametersDoc and Parameters in parametrizable.cpp
In order to get more consistent tests results with the Python version examples.
Added the suffix _const at the end of the method signature
Copy link
Contributor

@YoshuaNava YoshuaNava left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @AlexandreG87,
This PR looks really cool. Just left a few minor comments.

pointmatcher/IO.cpp Show resolved Hide resolved
python/pointmatcher/io.cpp Outdated Show resolved Hide resolved
python/pointmatcher/io.cpp Outdated Show resolved Hide resolved
CMakeLists.txt Show resolved Hide resolved
doc/CompilationPython.md Show resolved Hide resolved
examples/align_sequence.cpp Outdated Show resolved Hide resolved
python/CMakeLists.txt Outdated Show resolved Hide resolved
python/CMakeLists.txt Outdated Show resolved Hide resolved
python/datapointsfilters/covariancesampling.cpp Outdated Show resolved Hide resolved
@@ -0,0 +1,72 @@
#ifndef PYTHON_PYPOINTMATCHER_HELPER_H
#define PYTHON_PYPOINTMATCHER_HELPER_H

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name of this file is not very clear. To me it is more like a centralized typedefs-header.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it ended up being that way, but in the main purpose of this file was to regroup all the necessary include in one place and also the PYBIND11_MAKE_OPAQUE macro declaration as mentioned in pybind11 documentation. I thought about whether I put these aliases just before their use, like the io.cpp source file, or in a common header file like it is right now. Some of them are used across some other files, so I did this to avoid re-declaring them every time I needed it. But, if you suggest that it would be better to declare it only where it is needed (saying that make me realize that it makes much more sense to do so 😅), I have no problem to fix this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey. For now I think it's ok to keep the file. But I would rename it to pypointmatcher_typedefs or pypointmatcher_types. It would be easier to understand its content.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I'll see what I can do about that.

@aguenette
Copy link
Member Author

@YoshuaNava Thank you for the feedback and I hope you will be satisfied with my answers. 😄

Now giving the possibility to choose between system installed pybind11 and a git sub-module by setting USE_SYSTEM_PYBIND11 variable.
Also, making PLYProperties and PLYDescPropMap typedefs opaque in order to avoid unwanted behavior.
A copy was made every time it was called because no return value policy was specified.
@YoshuaNava
Copy link
Contributor

YoshuaNava commented Aug 22, 2020

@YoshuaNava Thank you for the feedback and I hope you will be satisfied with my answers.

I am, thank you for addressing all of them. Really cool work ⚡

I left just a few minor comments. Most of the items are resolved in my opinion.

Before approving I have some final questions:

  1. On which platforms have you tested the bindings?
  2. Which versions of Python are you supporting? Is there any performance variation or change needed to run with Python 2/3?
  3. Have you tested both building/running, but also installing the bindings? If so, where do they get installed?
  4. Does the uninstall target also remove the bindings?

@YoshuaNava
Copy link
Contributor

@AlexandreG87 What is the status of this PR?

  • I can give this a try under Windows. Do you also plan to test the bindings generation when compiling with ROS?

@aguenette
Copy link
Member Author

aguenette commented Sep 13, 2020

@AlexandreG87 What is the status of this PR?

Hi @YoshuaNava, I would say that it's not quite finished yet. I'll start to address your comments first, then we'll see what needs to be done to make it better.

  • I can give this a try under Windows.

Thanks, it's very appreciated. Maybe, I'll give it a try too.

Do you also plan to test the bindings generation when compiling with ROS?

It was not in my plans, I'll need to check with @pomerlef what can be done about that.

@aguenette
Copy link
Member Author

Before approving I have some final questions:

1. On which platforms have you tested the bindings?

2. Which versions of Python are you supporting? Is there any performance variation or change needed to run with Python 2/3?

3. Have you tested both building/running, but also installing the bindings? If so, where do they get installed?

4. Does the uninstall target also remove the bindings?
  1. So far, I've only been testing on Ubuntu 18.04 with Python 3.6.9 and pybind11 2.5.0.

  2. We will support Python 3 only, since Python 2 is deprecated.

  3. Yes, I've tested building and running, but also installing. You can find these answers in the compilation tutorial.

  4. Yes, it does.

@YoshuaNava
Copy link
Contributor

@AlexandreG87 Regarding your answers:

Thanks, it's very appreciated. Maybe, I'll give it a try too.

Oki.

It was not in my plans, I'll need to check with @pomerlef what can be done about that.

I would say that for minimum support we should make sure that the ROS build still runs. In a separate PR I plan to submit a new CMake setup, that allows you to have ROS CI/CD, running tests, and at the same time build without catkin, in case wanted. I'll open an issue to propose it.

  1. So far, I've only been testing on Ubuntu 18.04 with Python 3.6.9 and pybind11 2.5.0.
  2. We will support Python 3 only, since Python 2 is deprecated.

That's good 👍

image

  1. Yes, I've tested building and running, but also installing. You can find these answers in the compilation tutorial.
  2. Yes, it does.

Very good. No more comments from my side apart from the open ones.

simonpierredeschenes pushed a commit to simonpierredeschenes/libpointmatcher that referenced this pull request Oct 17, 2020
@pomerlef
Copy link
Collaborator

I would go on an merge this PR and open issues if something go wrong. For now, I don't have time to test it on MacOs.

@aguenette
Copy link
Member Author

I would go on an merge this PR and open issues if something go wrong. For now, I don't have time to test it on MacOs.

@pomerlef There were some more things that I wanted to do before you merge this PR and I will do them as soon as possible.

@aguenette
Copy link
Member Author

@pomerlef You can proceed to the merge when you're ready.

@pomerlef pomerlef merged commit 99d2937 into norlab-ulaval:master Nov 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants