From kgabor79 at gmail.com  Fri Jun 10 11:49:53 2016
From: kgabor79 at gmail.com (Gabor Kovacs)
Date: Fri, 10 Jun 2016 16:49:53 +0100
Subject: [C++-sig] C++ destructor calling of boost.python wrapped objects
Message-ID: <CAPhngs4yuATTh9nwX2dF-TQ+qUT4p1q=aOnLMeLs1axcqpdhaA@mail.gmail.com>

Dear All,

does boost.python provide any guarantee when the C++ destructor of a
wrapped object is called considering the moment of reaching the zero
reference count of the python object? I am concerned about a C++
object that does some I/O (file close) at its destruction.

I mean:

A=MyBoostPythonObject()
del A # Is the C++ destructor of MyBoostPythonObject called here?

Thanks,
Gabor

From stefan at seefeld.name  Sat Jun 18 00:25:08 2016
From: stefan at seefeld.name (Stefan Seefeld)
Date: Sat, 18 Jun 2016 00:25:08 -0400
Subject: [C++-sig] Stand-alone Boost.Python
Message-ID: <ecad28cf-514d-e302-b4ce-d15aba3c09c8@seefeld.name>

Hello,


I have started working on a new SCons-based build infrastructure for
Boost.Python that allows the Boost.Python code to be compiled
stand-alone against a pre-installed Boost. I have checked in a first
version to the develop branch, and have enabled Travis-CI to use that.

While this works reasonably well, and provides a much simpler workflow
for developers wanting to contribute to Boost.Python, it isn't (yet)
entirely feature-complete. Notably, running this on Windows (using MSVC)
produces errors. I'd appreciate any help with this, especially from
Windows users who are more familiar with MSVC than I am (that shouldn't
be hard, given I have next to no experience with using MSVC :-) ).

Building Boost.Python is now very simple:

* clone the repo via `git clone https://github.com/boostorg/python.git`
and switch to the 'develop' branch

* configure a build via `scons config --python=... --boost-prefix=...`

* build and test via `scons test`

Hopefully this will make it much simpler to contribute and test patches,
so we can work down the list of accumulated PRs and issues.

(For avoidance of doubt: for the immediate future I have no intentions
to replacing the official bjam-based build system. But once the new one
has proven to be stable enough, I expect to actually build stand-alone
releases for Boost.Python.)

Thanks,

        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From skip.montanaro at gmail.com  Fri Jun 17 09:37:10 2016
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Fri, 17 Jun 2016 08:37:10 -0500
Subject: [C++-sig] Getting Boost.Python to explain itself better?
Message-ID: <CANc-5UwRnKcSwUJAg4qMby_NdqN2V-bsZ58QTi68RWQgQ+yxkg@mail.gmail.com>

I'm trying to debug an assertion error from Boost.Python, but having
no luck. I'm not a C++ programmer, but to my eyes, it seems like my
call should work. I'm using Boost 1.47.0 on an openSuSE 12.2 platform,
with GCC/G++ 4.4. These parameters are fixed (that is, suggestions
that I update any of them aren't going to fly - I am tied to those
versions by factors outside my control). Here's a simple example,
which used to work:

>>> service.Provider
<class 'tradelink.service.v9_4.service.Provider'>
>>> pro = service.Provider("Skip-hacking")
>>> pro2 = service.Provider("Skip-hacking", {})
>>> pro3 = service.Provider("Skip-hacking", {}, 4001)

I'm upgrading to accommodate some internal version dependency changes
in other internal libraries, which should (in theory) have no effect
on the build and functioning of the Boost.Python wrappers, certainly
of this particular wrapper. Still, something's amiss. Here's the same
example using my new version:

>>> service.Provider
<class 'tradelink.service.v9_5.service.Provider'>
>>> pro = service.Provider("Skip-hacking")
>>> pro2 = service.Provider("Skip-hacking", {})
ArgumentError Python argument types in
    Provider.__init__(Provider, str, dict)
did not match C++ signature:
    __init__(boost::python::api::object, std::string,
std::map<std::string, resource::variant, std::less<std::string>,
std::allocator<std::pair<std::string const, resource::variant> > >,
int)
    __init__(boost::python::api::object, std::string,
std::map<std::string, resource::variant, std::less<std::string>,
std::allocator<std::pair<std::string const, resource::variant> > >)
    __init__(boost::python::api::object, std::string)
[<stdin>|<module>|1]
>>> pro3 = service.Provider("Skip-hacking", {}, 4001)
ArgumentError Python argument types in
    Provider.__init__(Provider, str, dict, int)
did not match C++ signature:
    __init__(boost::python::api::object, std::string,
std::map<std::string, resource::variant, std::less<std::string>,
std::allocator<std::pair<std::string const, resource::variant> > >,
int)
    __init__(boost::python::api::object, std::string,
std::map<std::string, resource::variant, std::less<std::string>,
std::allocator<std::pair<std::string const, resource::variant> > >)
    __init__(boost::python::api::object, std::string)
[<stdin>|<module>|1]

It seems that Boost.Python doesn't think my empty dictionary is
compatible with the std::map<...> type. Even if I pass a small,
populated dictionary, it barfs:

>>> pro4 = service.Provider("Skip-hacking", {"name": "skip"})
ArgumentError Python argument types in
    Provider.__init__(Provider, str, dict)
did not match C++ signature:
    __init__(boost::python::api::object, std::string,
std::map<std::string, resource::variant, std::less<std::string>,
std::allocator<std::pair<std::string const, resource::variant> > >,
int)
    __init__(boost::python::api::object, std::string,
std::map<std::string, resource::variant, std::less<std::string>,
std::allocator<std::pair<std::string const, resource::variant> > >)
    __init__(boost::python::api::object, std::string)
[<stdin>|<module>|1]

The upgrade was only for version dependencies (we live in version
dependency hell at work). There were no code changes to either the
Boost.Python wrapper or the underlying C++ libraries between versions
9.4 and 9.5. In fact, this is very basic stuff in our environment
which hasn't changed functionally in several years.

I'd appreciate some insight about Boost.Python's thought processes.
Why doesn't it like my dictionaries (empty or populated)?

Thanks,

Skip

From skip.montanaro at gmail.com  Fri Jun 17 11:21:26 2016
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Fri, 17 Jun 2016 10:21:26 -0500
Subject: [C++-sig] Getting Boost.Python to explain itself better?
In-Reply-To: <CANc-5UwRnKcSwUJAg4qMby_NdqN2V-bsZ58QTi68RWQgQ+yxkg@mail.gmail.com>
References: <CANc-5UwRnKcSwUJAg4qMby_NdqN2V-bsZ58QTi68RWQgQ+yxkg@mail.gmail.com>
Message-ID: <CANc-5Uwf6u3u7Qh_g7DEbfJoSzftAszxhHBWz2OvO+d5HVV1Dg@mail.gmail.com>

On Fri, Jun 17, 2016 at 8:37 AM, Skip Montanaro
<skip.montanaro at gmail.com> wrote:
>
> >>> pro2 = service.Provider("Skip-hacking", {})
> ArgumentError Python argument types in
>     Provider.__init__(Provider, str, dict)
> did not match C++ signature:
>     __init__(boost::python::api::object, std::string,
> std::map<std::string, resource::variant, std::less<std::string>,
> std::allocator<std::pair<std::string const, resource::variant> > >,
> int)
>     __init__(boost::python::api::object, std::string,
> std::map<std::string, resource::variant, std::less<std::string>,
> std::allocator<std::pair<std::string const, resource::variant> > >)
>     __init__(boost::python::api::object, std::string)
> [<stdin>|<module>|1]

After a bit more digging I think I found the problem, but am unclear
how to solve it. Down a couple levels of dependencies there is a
resource library in which a variant class is defined. It can contain
int, string or bool objects, and uses a discriminator to decide which
field is active. Kind of a union but without overlapping fields. (I
make no comment on this class. It is what it is. I just have to live
with it.) Structurally, it looks like this:

class variant {
public:
  ...
  enum Which {
    NONE = 0x00,
    INT  = 0x01,
    STR  = 0x02,
    BOOL = 0x03
  };
  ...
private:
  Which which_;
  int i_;
  std::string s_;
  bool b_;
}

Somewhere along the way, someone needed to use one of these variants
in a context where two variants needed to be compared, so a public
operator< method was added. The data layout of the class instances
didn't change. My programs were happily communicating with a server
running the newer version of the class while it still relied on the
older version.

The addition of that public operator< method is what seems to have
tripped up Boost.Python. Is there some way to convince it to accept
the version of the variant class which contains this method?

Thx,

Skip

From stefan at seefeld.name  Sat Jun 18 14:07:56 2016
From: stefan at seefeld.name (Stefan Seefeld)
Date: Sat, 18 Jun 2016 14:07:56 -0400
Subject: [C++-sig] Getting Boost.Python to explain itself better?
In-Reply-To: <CANc-5UwRnKcSwUJAg4qMby_NdqN2V-bsZ58QTi68RWQgQ+yxkg@mail.gmail.com>
References: <CANc-5UwRnKcSwUJAg4qMby_NdqN2V-bsZ58QTi68RWQgQ+yxkg@mail.gmail.com>
Message-ID: <1b6f7b11-afd1-bf19-9a71-dc5aa8cb89ce@seefeld.name>

Hi Skip,

On 17.06.2016 09:37, Skip Montanaro wrote:
> I'm trying to debug an assertion error from Boost.Python, but having
> no luck. I'm not a C++ programmer, but to my eyes, it seems like my
> call should work. I'm using Boost 1.47.0 on an openSuSE 12.2 platform,
> with GCC/G++ 4.4. These parameters are fixed (that is, suggestions
> that I update any of them aren't going to fly - I am tied to those
> versions by factors outside my control). Here's a simple example,
> which used to work:

you haven't shown any code, so I can only guess, but from the error
messages I'd suspect you assume Boost.Python to automatically map
between the Python dict type and your library's std::map<std::string,
resource::variant>. There is no automatic mapping of std::map<...>. The
closest is the "map_indexing_suite"
(http://boostorg.github.io/python/doc/html/reference/topics/indexing_support.html#topics.indexing_support.class_map_indexing_suite),
but even with that you do need to explicitly specify the types to map.

HTH,
        Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From stefan at seefeld.name  Mon Jun 20 07:53:18 2016
From: stefan at seefeld.name (Stefan Seefeld)
Date: Mon, 20 Jun 2016 07:53:18 -0400
Subject: [C++-sig] Stand-alone Boost.Python
In-Reply-To: <20160620103508.a879865232b91e4285def7b4@weightpack.com>
References: <ecad28cf-514d-e302-b4ce-d15aba3c09c8@seefeld.name>
 <20160620103508.a879865232b91e4285def7b4@weightpack.com>
Message-ID: <df961213-47e2-a80e-e2a1-6d0a0f729794@seefeld.name>

On 20.06.2016 04:35, Giuseppe Corbelli wrote:
> On Sat, 18 Jun 2016 00:25:08 -0400 Stefan Seefeld <stefan at seefeld.name>
> wrote:
>> Hello,
>> I have started working on a new SCons-based build infrastructure for
>> Boost.Python that allows the Boost.Python code to be compiled
>> stand-alone against a pre-installed Boost. I have checked in a first
>> version to the develop branch, and have enabled Travis-CI to use that.
>>
>> While this works reasonably well, and provides a much simpler workflow
>> for developers wanting to contribute to Boost.Python, it isn't (yet)
>> entirely feature-complete. Notably, running this on Windows (using MSVC)
>> produces errors. I'd appreciate any help with this, especially from
>> Windows users who are more familiar with MSVC than I am (that shouldn't
>> be hard, given I have next to no experience with using MSVC :-) ).
> I can be of some (testing) help.
> Cloned the repo, configured for x86 target.
>
> arch = 'x86'
> toolchain = 'msvc'
>
> First thing that I notice is that the /arch compiler option is missing (1).
> The commandline is (cut include dirs):
> cl /Fobin.SCons\msvc-14.0\release\dynamic\threading-multi\test
> \andreas_beyer.obj /c bin.SCons\msvc-14.0\release\dynamic\threading-multi
> \test\andreas_beyer.cpp /TP /nologo
> -TP /Z7 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs /DBOOST_ALL_NO_LIB=1 /DNDEBUG 
>
> In this way the compiler relies on the default architecture.

which should be fine. Note that the 'arch' flag is used to initialize
the environment, so the appropriate vcvars* script is read.
Let's follow up with details on
https://github.com/boostorg/python/issues/72 so we don't pollute this
list with technical details.

Many thanks !

        Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From giuseppe.corbelli at weightpack.com  Mon Jun 20 04:35:08 2016
From: giuseppe.corbelli at weightpack.com (Giuseppe Corbelli)
Date: Mon, 20 Jun 2016 10:35:08 +0200
Subject: [C++-sig] Stand-alone Boost.Python
In-Reply-To: <ecad28cf-514d-e302-b4ce-d15aba3c09c8@seefeld.name>
References: <ecad28cf-514d-e302-b4ce-d15aba3c09c8@seefeld.name>
Message-ID: <20160620103508.a879865232b91e4285def7b4@weightpack.com>

On Sat, 18 Jun 2016 00:25:08 -0400 Stefan Seefeld <stefan at seefeld.name>
wrote:
> Hello,
> I have started working on a new SCons-based build infrastructure for
> Boost.Python that allows the Boost.Python code to be compiled
> stand-alone against a pre-installed Boost. I have checked in a first
> version to the develop branch, and have enabled Travis-CI to use that.
> 
> While this works reasonably well, and provides a much simpler workflow
> for developers wanting to contribute to Boost.Python, it isn't (yet)
> entirely feature-complete. Notably, running this on Windows (using MSVC)
> produces errors. I'd appreciate any help with this, especially from
> Windows users who are more familiar with MSVC than I am (that shouldn't
> be hard, given I have next to no experience with using MSVC :-) ).

I can be of some (testing) help.
Cloned the repo, configured for x86 target.

arch = 'x86'
toolchain = 'msvc'

First thing that I notice is that the /arch compiler option is missing (1).
The commandline is (cut include dirs):
cl /Fobin.SCons\msvc-14.0\release\dynamic\threading-multi\test
\andreas_beyer.obj /c bin.SCons\msvc-14.0\release\dynamic\threading-multi
\test\andreas_beyer.cpp /TP /nologo
-TP /Z7 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs /DBOOST_ALL_NO_LIB=1 /DNDEBUG 

In this way the compiler relies on the default architecture.

1: https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx

-- 
        Giuseppe Corbelli
Software Engineer - Weightpack SRL
<giuseppe.corbelli at weightpack.com>