github-actions[bot] on gh-pages
deploy: 8dd151177374dbf0aa5cb86… (compare)
vswhereshould be at
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe, see
vswherebe found ?
vswhere. Otherwise you could
set PATH=%PATH%;%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\
vswhereto the system path.
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\in cmd.exe ?
The shell variable
%ProgramFiles(x86)% points to
C:\Program Files (x86) on almost all computers, I'm guessing a very small percentage have a non C: drive as their default.
From my understanding VS 2017 (15.2+) and VS 2019 will always install
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.
cl /nologo /showIncludes /EP ..., then I scan the output (stderr !) for "Note: including file: ". I just realized that this only works for English locales. Do you know of a way (under Windows) to set the locale just for a specific subprocess (such as
cl ...) ?
boost::) as HeldType ? Wouldn't that solve the issue, as in that case the type would always be allocated on the heap on a correctly aligned memory boundary, rather than being forced into a specific location in the pre-allocated PyObject ?
shared_ptrheld type idea you mentioned has worked for fixing some alignment-related crashes in the past. However, as in the original issue, the error also seems to occur in bound member functions that return
Eigen::Matrixtypes, which are converted to numpy arrays via custom converters. The key part of the conversion to python is the call to numpy::from_data, followed by a copy(). I'm wondering if the issue is there, I need to look into it.
alignas()attribute to its types directly ?
Boost.Python's use of placement operator new as being problematic, as that overrides a type's alignment requirements, so that's one of the things I'm looking into fixing now.
boost-python-test-dockerdocker image, which installs boost prerequisite libs via
bcp python. As it happens, my PR adds another prerequisite (boost.align), and thus the build fails as that isn't installed. I'm not sure what the best is to solve this. Would it make sense to modify those docker images to install all of boost (and perhaps remove boost.python, to avoid potential conflicts), rather than only what the old
boost.pythonwould depend on ?
@stefanseefeld I've got a problem, this commit (ecda18f01e252134090804d01219d90c7c1380c1) seems to have broken all my regression test runners.
I'm seeing an error that looks like this:
- lzma : yes  - zstd : no  - lzma : yes (cached)  - has_lzma_cputhreads builds : no  - auto_ptr : yes  error: Unable to find file or target named error: '/python//numpy' error: referred to from project at error: '../libs/python/build'
I'm not sure what that commit mean, but I've been using this (teeks99/boost-cpp-docker:clang-11) or a similar docker image for a long time. It has numpy installed for both python 2 and 3.
Boost.Buildas per the comment from that PR.