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

Python wrapper of the solver #493

Open
wants to merge 104 commits into
base: master
Choose a base branch
from
Open

Python wrapper of the solver #493

wants to merge 104 commits into from

Conversation

@KmolYuan
Copy link

@KmolYuan KmolYuan commented Oct 12, 2019

#292 The first pull request of Python wrapper branch.

New folder:

  • cython

Modified files:

  • .gitignore: Ignore the project settings of JetBrains IDE.
  • .travis.yml and appveyor.yml: Deployment of PyPI.
  • src/platform/platform.cpp: Add a type cast for MinGW and newer version compiler.
@vespakoen
Copy link
Contributor

@vespakoen vespakoen commented Oct 26, 2020

Hey! This is really cool!

I wonder if the code in cython/setup.py could be simplified, perhaps if we made a new target / compile option in CMakeLists.txt?

I was thinking of making a Node.js wrapper (NAPI) and webassemby build some day for the core, and want to see if we can reduce the duplication somehow.

What were the biggest problems you ran into and what could have made it easier?

Loading

@ruevs
Copy link
Member

@ruevs ruevs commented Oct 26, 2020

Loading

@vespakoen
Copy link
Contributor

@vespakoen vespakoen commented Oct 26, 2020

Yes I have seen the webassembly version, but I would like to package up the core only as a Node.js / browser package.

Loading

@phkahler phkahler force-pushed the master branch 2 times, most recently from dfb96de to 3f09eaf Nov 7, 2020
@blooop
Copy link

@blooop blooop commented Dec 15, 2020

I'd just like to say that I am very interested in python bindings for an up to date version of solvespace, so this pr looks great.

Thanks

Loading

@vespakoen
Copy link
Contributor

@vespakoen vespakoen commented Dec 15, 2020

I think providing SolveSpace's solver as a library would be great for many other projects, and also hopefully would get more people working / improving on it.

It would be great if the SolveSpace CI can produce these libraries automatically for every platform.

The most "universal" way I think is by using pybind (For Python), embind (For the web) and n-api (For node.js), they are all very similar, and work the best by wrapping a class.

Also, by moving as much logic as we can into a C++ class, the bindings can be smaller, and there is less "wrapper code" that we would have to maintain.

I would happily take on the job of hooking it into our CI to have it produce the libraries for all the platforms, I just don't know what this class should look like exactly.

Anyways, this is definitely something I want to take a look at in the near future.

Loading

@blooop
Copy link

@blooop blooop commented Dec 15, 2020

That sounds great. I agree about pybind11 for python bindings, I found it very easy to generate bindings with minimal extra code/maintenance.

I have been looking into cadquery for code based CAD, but am still struggling to work out the right code to do things. I read this paper: https://onlinelibrary.wiley.com/doi/full/10.1111/cgf.14046

which basically says, gui cad is quick and easy to use, but not as robust as code, but code is difficult to understand. They come up with a dual system which allows gui creation but also saves a code representation so gets the best of both worlds.

I was thinking of trying to do something similar with solvespace but I'm guessing it will be a lot of work.

Loading

@vespakoen
Copy link
Contributor

@vespakoen vespakoen commented Dec 15, 2020

CadQuery is a very cool project indeed, there is also OpenSCAD (and OpenJSCAD) which might be of interest to you.

And I guess we should not forget "SWIG" for generating external bindings to SolveSpace, maybe it's even the least invasive but I have no experience using it yet.

Loading

@blooop
Copy link

@blooop blooop commented Dec 15, 2020

I started out with openSCAD, but it doesn't have operations like fillet or shell and the language itself is not as nice a python.

Cadquery fixes those problems but doesn't have constraints so is still rather procedural. Freecad in theory has everything, but when I started implementing basic programmatic 2D sketching constraints everything was very slow and crashed all the time.

And now we come to solvespace, which appears to have everything. I'm still very early in the research stage so I need to investigate the solvespace code more, but I've been using the editor as my CAD of choice for a while now and have been impressed so far.

In terms of SWIG, I have not used it, but did not like the look of it compared to pybind11 which I've been using on a large project quite happily for over a year now.

Loading

@phkahler
Copy link
Member

@phkahler phkahler commented Dec 15, 2020

@vespakoen The reason this is still not merged is I'm not sure what to make of it, and not planning to use it soon. Not even sure what the use cases are yet - to bring the solver to python programs, or to bring python to solvespace? It obviously useful to someone! If you want to take it on we can merge it - probably after 3.0.

It would also be good to squash most of the commits. Down to 5ish?

Loading

@blooop
Copy link

@blooop blooop commented Dec 15, 2020

In terms of the use case of bringing the solver to python, it would be useful because then I could add constraints to Cadquery relatively easily which removes one of its biggest weaknesses.

Loading

@ruevs
Copy link
Member

@ruevs ruevs commented Dec 15, 2020

we can merge it - probably after 3.0.

It would also be good to squash most of the commits. Down to 5ish?

Does a python whapper of the solver belong in the same repository as the application?

Loading

@robnee
Copy link
Contributor

@robnee robnee commented Mar 5, 2021

Does a python whapper of the solver belong in the same repository as the application?

The python module seems to depend on mostly the same src/ files as libslvs. Could the python module depend on libslvs instead?

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants