Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 20 08:29
    kaustubhcs commented #333
  • Jun 10 19:44
    shkoo closed #269
  • Jun 04 03:57
    vitalybuka synchronize #387
  • Jun 04 03:54
    vitalybuka opened #387
  • May 23 14:23
    bernhardu commented #312
  • May 18 09:48
    joriscarrier commented #380
  • 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
Stefan Seefeld
@stefanseefeld
Ok, thanks. I'll take a look
Stefan Seefeld
@stefanseefeld
does it have boost pre-installed ? In fact, on a tangential note: is there a way to install a (pre-packaged) boost binary package, say, from vcpkg ?
Tom Kent
@teeks99
No, it isn't pre-installed, the goal of that image was to get the tools there to build boost. It is pretty easy to make another image on top of that, where the dockerfile pulls in the source and builds that in the appropriate config(s).
I don't think vcpkg does binaries, I was under the impression it was just a way to build source. Conan might have binaries? We could also just grab the windows binaries from sourceforge.
Stefan Seefeld
@stefanseefeld
Hi @teeks99 , I'm trying a Windows workflow (https://github.com/stefanseefeld/boost.python/blob/actions/.github/workflows/test-windows.yml), but get the error "Error: Container operations are only supported on Linux runners" (https://github.com/stefanseefeld/boost.python/runs/1609468749?check_suite_focus=true). Am I misunderstanding what you explained earlier ?
Tom Kent
@teeks99
Interesting, I've never tried containers with the windows github actions. This might be one of the effects I was fearing when I said that docker isn't fully baked on windows.
Tom Kent
@teeks99
Running C:\Program Files\Docker\Docker\DockerCLI.exe -SwitchWindowsEngine should (might?) make it compatible. Not sure how that would fit into the yaml file though....when that runs vs. when the image starts would have to be coordinated.
Tom Kent
@teeks99
Interestingly, at the end of the page detailing features of the windows image it lists a bunch of windows docker containers as resident in the image....yet it doesn't seem to be configured to run them by default.
Stefan Seefeld
@stefanseefeld
OK, so I have started experimenting a bit with Windows. Here is how far I have got: https://github.com/boostorg/python/pull/342/files
There is an action to install MSVC (https://github.com/boostorg/python/pull/342/files#diff-9e2bbc2329bfb445d0985173b98e981dd7fbf69428e7addd83d453e8d5f3ff2dR15). However, I was expecting this to also make the vswhere tool available, but faber then can't find it, so the build fails: https://github.com/boostorg/python/pull/342/checks?check_run_id=1612000557
Any idea how to fix this ? I thought vswhere is bundled with MSVC nowadays.
Stefan Seefeld
@stefanseefeld
(For now I'm installing boost prerequisite libs via vcpkg (https://github.com/boostorg/python/pull/342/files#diff-9e2bbc2329bfb445d0985173b98e981dd7fbf69428e7addd83d453e8d5f3ff2dR19-R22). Still need to figure out how to cache things properly so they don't get recompiled each time. It takes half an hour to build without caching...
and I completed the transition away from travis-ci by adding a workflow for OSX and another one to build and deploy Boost.Python documentation.
@teeks99 thanks again for kicking of that work !
Tom Kent
@teeks99
vswhere should be at %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe, see
Stefan Seefeld
@stefanseefeld
What is the meaning of %ProgramFiles(x86)% ? Is that a variable substitution ?
what do I need to do to make vswhere be found ?
Tom Kent
@teeks99
That's the variable that on 99.9% of windows computers points to C:\Program Files (x86)\.
Running that at a command prompt would execute vswhere. Otherwise you could set PATH=%PATH%;%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\
Stefan Seefeld
@stefanseefeld
OK, thanks. Do I need to call that set ... in each "run" block ? Or would that be memorized ? (the equivalent of export PATH in bash)
Tom Kent
@teeks99
I'd guess in each one, but honestly I'd just use the full path to the executable.
How many times do you need vswhere?
Stefan Seefeld
@stefanseefeld
That's the problem: faber calls vswhere in each invocation where I need to load an MSVC instance.
So I need a generic solution. I was expecting that an MSVC installation would automatically add vswhere to the system path.
Tom Kent
@teeks99
Faber should probably use the hard-coded (ish) path. vswhere does not get added to a PATH variable by default on any install, but that location is going to be supported by MS going forward
Or at least have faber check to see if the supported path exists before going on (and using the bare call or failing)
Stefan Seefeld
@stefanseefeld
Yeah, that makes sense.
So just to be entirely sure I understand: There is indeed a variable called "ProgramFiles (x86)" on Windows, which gets substituted approrpriately when evaluating e.g. %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\ in cmd.exe ?
(and in 99% the value of the variable is identical to the name of the variable ?)
Tom Kent
@teeks99

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 vswhere to %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.

Stefan Seefeld
@stefanseefeld
Funny name for a variable...but OK. I'll add some unit tests to faber to solidify its handling of MSVC toolchains, then prepare a fix and a release, which I can then use in Boost.Python.
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.