Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 16 14:15
    glaure commented #386
  • May 16 14:11
    glaure closed #386
  • May 16 14:11
    glaure commented #386
  • May 16 13:35
    glaure edited #386
  • May 16 13:32
    glaure opened #386
  • Apr 26 14:09

    github-actions[bot] on gh-pages

    deploy: a218babc8daee904a83f550… (compare)

  • Apr 26 13:42

    stefanseefeld on develop

    Fix enum_type_object type on Py… (compare)

  • Apr 26 13:42
    stefanseefeld closed #385
  • Apr 26 13:42
    stefanseefeld commented #385
  • Apr 26 13:26
    vstinner commented #385
  • Apr 26 13:20
    vstinner commented #385
  • Apr 25 08:58
    vstinner commented #385
  • Apr 25 08:57
    vstinner commented #385
  • Apr 25 08:53
    vstinner opened #385
  • Apr 19 15:07
    cas-- closed #270
  • Apr 13 16:09

    github-actions[bot] on gh-pages

    deploy: 8dd151177374dbf0aa5cb86… (compare)

  • Apr 13 14:41

    mclow on boost-1.79.0

    (compare)

  • Apr 12 07:16
    jakirkham commented #282
  • Apr 05 14:19
    aristk edited #384
  • Apr 05 13:38
    Minimonium commented #384
Stefan Seefeld
@stefanseefeld
Hi @teeks99 , I'v run into a curious problem: To extract header dependencies from MSVC I run 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 ...) ?
Tom Kent
@teeks99
Nope, never messed with locales on windows.
KoushikAD1234
@KoushikAD1234
Hii Everyone! I'm a first year B.Tech Electronics and communication engineering student. I would like to start contributing to Boost C++ libraries as I highly intereseted in Coding as well as development and also want to participate in GSoC 2021 under this Organisation. Will somebody help me?
Stefan Seefeld
@stefanseefeld
@KoushikAD1234 please follow the guidelines referenced in reply to your question in other channels (e.g. boostorg/ublas). If you have specific question concerning Boost.Python, I'm happy to help.
Ali Hussain Khan
@ahk4815
Hello everyone,
This is Ali Hussain Khan, 4th year undergrad from Jadavpur University in computer science engineering. I have experience in working with c, c++, python. I would like to contribute and add value to Boost. Can anyone help me get started
Stefan Seefeld
@stefanseefeld
Hello, and welcome ! The very first step is to get set up with Boost as a development platform, i.e. be able to compile it (or at least, the subset of it you are interested in), and work your way through the various examples. Once that's done we can talk about any specific interest(s) you may have.
pacidic
@pacidic
Hi, I think I've run into this alignment issue: boostorg/python#27 and since there aren't many comments I'm wondering if the referenced but unmerged PR (boostorg/python#35) already fixes it, or if there is further work required. Does anyone know more details? Thanks.
Stefan Seefeld
@stefanseefeld
Hi @pacidic . I admit I was mostly hesitant as I'm afraid of introducing backward incompatibilities. Meanwhile, the original PR isn't mergeable due to conflicts. I suppose I should look at it again.
pacidic
@pacidic
Thanks for the info. The merge conflicts are also what is stopping me from trying out the patch in the version of boost I'm working with. I don't know the internals of boost.python well enough to be able to fix those.
Stefan Seefeld
@stefanseefeld
The only major change I can think of affecting this is my adding support for C++11, specifically std::shared_ptr, many years ago. I will have a look. These conflicts ought to be easy to resolve.
pacidic
@pacidic
Thanks a lot!
Stefan Seefeld
@stefanseefeld
hi @pacidic , I have been looking into boostorg/python#35 , especially rebasing it to make it compile with current master, but eventually stopped as I realized that this PR seriously breaks backward compatibility, at least for people who write custom converters.
While I'm still thinking about ways to fix boostorg/python#27 without such breakage, I wonder: can you solve your problem by using a shared_ptr (either std:: or 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 ?
pacidic
@pacidic
hi @stefanseefeld, thanks for looking into it. Indeed, using theshared_ptr held 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::Matrix types, 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.
Stefan Seefeld
@stefanseefeld
I was always irritated by Eigen and its strange handling of alignment. Why does it require user code to do anything special (e.g. https://eigen.tuxfamily.org/dox/group__TopicStructHavingEigenMembers.html), rather than adding the alignas() attribute to its types directly ?
And worse: why doesn't it contain checks that allow it to conditionally dispatch to non-vectorized implementations if the object happens to be un-aligned , rather than crashing ?
I can see 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.
Stefan Seefeld
@stefanseefeld
Hi @teeks99 , I'm running into a build issue on a new PR (boostorg/python#360). The reason (I believe) is that the builds use your boost-python-test-docker docker 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.python would depend on ?
by the way, @pacidic, boostorg/python#360 is my attempt to fix the alignment issue (this is a reworked version of boostorg/python#35). It's still WIP until I have sorted out the build issues, but it works fine for me locally with g++ 9. I haven't tried to build any Eigen extension modules, though.
Tom Kent
@teeks99
I've just uploaded new images for docker use teeks99/boost-python-test:clang-11_1.76.0 or teeks99/boost-python-test:gcc-9_1.76.0. These have the same path, /boost_py_deps, but instead of just bcping a few items, it is the entire release with boost/python and libs/python removed.
Tom Kent
@teeks99
Hang on, there was a bug with gcc-9's removal of python
Tom Kent
@teeks99
...but before that fix, I've got new images with a compiler roll:
  • teeks99/boost-python-test:clang-12_1.76.0
  • teeks99/boost-python-test:gcc-10_1.76.0
Tom Kent
@teeks99
okay, so I did something I should never do and re-pushed a tag (shhh)...teeks99/boost-python-test:gcc-9_1.76.0, should be good to go now, but I'd personally recommend moving to the newer compiler.
Stefan Seefeld
@stefanseefeld
@teeks99 Great ! I have adapted the CI logic to use your latest images (https://github.com/boostorg/python/pull/360/commits/4bf2d75910f4c7be0674fa831db18e4da3887f32) and everything is working fine. Thank you !
Stefan Seefeld
@stefanseefeld
@pacidic , I merged boostorg/python#360 last night. Please give it a try and let me know if you run into issues.
pacidic
@pacidic
Thanks, that's great. I did try to get your patch into boost 1.68.0, which is what I need to do in order to test it. I need to find time to get back to that. By the way, is there a simple way of generating an archive based on the development version that is identical in folder structure to the boost release archives?
Tom Kent
@teeks99

@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 [30]
    - zstd                     : no [30]
    - lzma                     : yes (cached) [30]
    - has_lzma_cputhreads builds : no [2]
    - auto_ptr                 : yes [3]
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.

Stefan Seefeld
@stefanseefeld
Hi @teeks99 , that was a PR from Peter Dimov (boostorg/python#362)
So perhaps you need to update Boost.Build as per the comment from that PR.
Tom Kent
@teeks99
Looks like that PR shouldn't have been merged yet, can you revert?
Stefan Seefeld
@stefanseefeld
Done