Update Pybind11 to v2.10.0 #2660
Conversation
|
I don't mind at all. Piecemeal PRs are better anyway. Shame Davis won't set minimum cmake version to 3.11. Then dlib could use FetchContent to pull in pybind rather than embed the source code. In fact, cmake could be really clever and if C++17 is detected, then use nanobind instead which is supposed to be a lot faster to compile and run. |
Ha, I'll update to 3.11 at some point. I'm surprised no one has complained to me yet about the upgrade to 3.8 :p I don't want to make people use FetchContent though. That will go sideways. Like someone will have the package to install dlib and then it will fail due to a network problem fetching that. Or they are off the internet or whatever. That will definitely throw off python users. |
|
I guess so. Offline builds are not uncommon. |
|
Ok, I don't know how to make macOS pick up the right version, I have never used a macOS device, so I am just shooting into the dark here… Why would they default to Python2? Has it been building on Python2 the whole time?? EDIT: Done, it was not so hard in the end :P |
| assert(dlib.partition_pixels(img[:,:,0].astype('float64')) == 125) | ||
| assert(dlib.partition_pixels(img[:,:,0].astype('uint16')) == 125) | ||
| assert(dlib.partition_pixels(img[:,:,0].astype('uint32')) == 125) | ||
| assert dlib.partition_pixels(img[:, :, 0].astype("uint8")) == 125 |
There was a problem hiding this comment.
I don't understand why this doesn't work anymore… When I print the type of img[:, :, 0], it is an ndarray of numpy.uint8.
|
Nice, thanks for the update :) |
I shamelessly stole @pfeatherstone's fix for the latest version of Pybind11 (v2.10.0) from #2636.
Let's see if the tests pass…