Re: [C++-sig] wrap union types with boost.python

[Stefan Seefeld]

On 2022-01-16 12:29, Malte Dreschert wrote:

Hi Stefan,

thanks for answering and a greetings from northern Germany to Berlin :)

the struct is meant to hold color values (three floats) but the color 
space can be different.
It contains three of these unions and one enum value that contains the 
information which color space was used when the values were written.

The floats are either rgb or hsv.

The library is for reading a binary file and I only have these structs 
and some methods I need to wrap, that means I only need to read the 
values.
I guess I would first check the color space and then interpret the 
three values accordingly.


Right, and I assume you already have a C++ API to access that struct, 
even if it isn't in terms of member functions. As far as the raw data 
type and its binary representation is concerned, there is nothing 
special here, i.e. you could wrap it in a Python object as-is. But what 
you likely want is a set of (member) functions to access the values, and 
that is very likely mapping to your C++ API more than mapping to the 
struct directly.


For example, let's assume you have:

```

struct someStruct {/*...*/};
float get_value(someStruct const &);
void set_value(someStruct &, float);

```

you may decide to map `get_value` and `set_value` to direct methods:

```

class_ s("someStruct");

s.def("get_value", get_value);

s.def("set_value", set_value);

```

(Notice how






Does that help? I don't want to post the code directly because it is 
in house code.


Thank you very much,

Cheers,

Malte


On Sun, Jan 16, 2022 at 4:18 PM Stefan Seefeld  
wrote:


Hi Malte,

the first step is for you to decide what semantics you want
`someStruct` to carry, which would then translate into an API.
This is also a prerequisite for using this in pure C++, i.e.
without any Python bindings. It just becomes more obvious if you
want to think about accessing this in a pythonic way.

So, can you rephrase your question by describing `someStruct` in
terms of behaviour rather than structure, i.e. in an
    "object-oriented" way ?

Stefan
-- 


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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] wrap union types with boost.python

[Stefan Seefeld]

On 2022-01-16 12:29, Malte Dreschert wrote:

Hi Stefan,

thanks for answering and a greetings from northern Germany to Berlin :)

the struct is meant to hold color values (three floats) but the color 
space can be different.
It contains three of these unions and one enum value that contains the 
information which color space was used when the values were written.

The floats are either rgb or hsv.

The library is for reading a binary file and I only have these structs 
and some methods I need to wrap, that means I only need to read the 
values.
I guess I would first check the color space and then interpret the 
three values accordingly.


Right, and I assume you already have a C++ API to access that struct, 
even if it isn't in terms of member functions. As far as the raw data 
type and its binary representation is concerned, there is nothing 
special here, i.e. you could wrap it in a Python object as-is. But what 
you likely want is a set of (member) functions to access the values, and 
that is very likely mapping to your C++ API more than mapping to the 
struct directly.


For example, let's assume you have:

```

struct someStruct {/*...*/};
float get_value(someStruct const &);
void set_value(someStruct &, float);

```

you may decide to map `get_value` and `set_value` to direct methods:

```

class_ s("someStruct");
s.def("get_value", get_value);
s.def("set_value", set_value);

```

(Notice how the freestanding functions lend themselves naturally to 
become methods as their first argument is the equivalent of the 
otherwise implied "this" pointer...)


Or you may want to map both directly to a property:

```

class_ s("someStruct");
s.add_property("value", get_value, set_value);
```

Either way, there is nothing special in this wrapping concerning the 
fact that your struct contains a union. Rather, it's your C++ API that 
will have to deal with that.


Regards (from Montreal ;-)),

Stefan

--

  ...ich hab' noch einen Koffer in Berlin...
null___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] wrap union types with boost.python

[Stefan Seefeld]

Hi Malte,

the first step is for you to decide what semantics you want `someStruct` 
to carry, which would then translate into an API. This is also a 
prerequisite for using this in pure C++, i.e. without any Python 
bindings. It just becomes more obvious if you want to think about 
accessing this in a pythonic way.


So, can you rephrase your question by describing `someStruct` in terms 
of behaviour rather than structure, i.e. in an "object-oriented" way ?


Stefan
--

  ...ich hab' noch einen Koffer in Berlin...
null___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python Wrong Python Version macOS

[stefan]

Hi Mortimer,

let me forward your message to the Boost.Build list, where I hope 
someone will take appropriate action.


Thanks,

On 2020-09-10 9:24 p.m., Mortimer Hemmit wrote:

Hi Stefan,

Thanks for the advice and the link; they were really helpful.
Just by itself, the line "using python : 3.7 ;" still returned an
error. However, upon reading the link, I could also specify the path
that leads to Python. So, I tried:

using python : 3.7 :
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7

Now, even without explicitly saying the python version,

sudo ./b2 install

began to use the right Python version. However, now the compiler
complained about not finding the file pyconfig.h. Looking at the
output, it seems like the build was specifying the following
nonexistent directory as an include path
"/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7/".
Actually, pyconfig.h is located inside
"/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m/".
Note the extra "m" at the end (I don't know what the m means though).
Anyway, as per the link you sent, I could add another path to the .jam
file to specify an include directory, so the final line was

using python : 3.7 :
"/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7" :
"/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m/"

Now it compiled relatively smoothly :)

Now, I tried getting it to work without making a user-specific file. I
looked at the boost folder and saw that inside "project-config.jam",
there was a section that said

if ! [ python.configured ]
{
 using python : 3.7 : "/Library/Frameworks/Python.framework/Versions/3.7"
}

When I ran it just like this, it still failed. However, when I edited
"project-config.jam" to go to the exact python executable (not just
the parent directory), it started working, but this time with the
header problem again.

using python : 3.7 :
"/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7"

So, I added the whole include line from my user file, and now it worked.

using python : 3.7 :
"/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7" :
"/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m/"

Ultimately, my prediction is that there are two problems:
1) The script ./bootstrap.sh, which generates the project-config.jam,
should print the full path to the python3.7 executable instead of just
the parent directory when given a --with-python=[executable] flag.
2) Somewhere in the build process, an include flag is missing an "m"
at the end which specifies the following nonexistent directory as an
include path 
"/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7/".
This prevents the compiler from finding pyconfig.h, causing an error.
Actually, pyconfig.h is located inside
"/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m/".

However, I'm not sure if these are specific to the version 3.7, or in general.

You have helped me a lot to get this working, and I hope this
information helps you (or someone else) find (and fix!) some of them.

Thank you very much,
Mortimer


On Mon, Sep 7, 2020 at 2:47 PM Stefan Seefeld  wrote:

Hi Mortimer,

On 2020-09-06 12:54 p.m., Mortimer Hemmit wrote:

Hi Stefan,

Apologies for breaking the reply chain; I wasn't subscribed to the
list earlier, so this is the only message I could reply to. Now I
should be able to reply to other messages.

Thanks for your email. I don't think that ./b2 has the option to
specify the python version within --with-python - I think only
./bootstrap does. When I tried

./b2 --with-python=3.7

I got;

*BEGIN OUTPUT*
error: wrong library name 'python=3.7' in the --with- option.
*END OUTPUT*

Then, I tried invoking ./b2 with option python=3.7.

sudo ./b2 python=3.7 --with-python

*BEGIN OUTPUT*
/Users/Mort/Downloads/boost_1_74_0/tools/build/src/build/feature.jam:491:
in feature.validate-value-string from module feature
error: "3.7" is not a known value of feature 
error: legal values: "2.7"

you are entirely right, there is no `--with-python` option to `b2`. Sorry for 
sending you down a wrong route.

I think what you need is described in 
https://www.boost.org/doc/libs/1_74_0/libs/python/doc/html/building/configuring_boost_build.html

Create a ~/user-config.jam file containing the line "using python : 3.7 ;"

This informs Boost.Build of the availability of that Python version (depending on 
your system you may want to add more parameters to specify paths, library name, 
etc.). You could define multiple versions (one per line), in which case the option 
`./b2 python=` will allow you to select one.

Hope this helps,

--

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

_

Re: [C++-sig] Boost Python Wrong Python Version macOS

[Stefan Seefeld]

Hi Mortimer,

On 2020-09-06 12:54 p.m., Mortimer Hemmit wrote:

Hi Stefan,

Apologies for breaking the reply chain; I wasn't subscribed to the
list earlier, so this is the only message I could reply to. Now I
should be able to reply to other messages.

Thanks for your email. I don't think that ./b2 has the option to
specify the python version within --with-python - I think only
./bootstrap does. When I tried

./b2 --with-python=3.7

I got;

*BEGIN OUTPUT*
error: wrong library name 'python=3.7' in the --with- option.
*END OUTPUT*

Then, I tried invoking ./b2 with option python=3.7.

sudo ./b2 python=3.7 --with-python

*BEGIN OUTPUT*
/Users/Mort/Downloads/boost_1_74_0/tools/build/src/build/feature.jam:491:
in feature.validate-value-string from module feature
error: "3.7" is not a known value of feature 
error: legal values: "2.7"


you are entirely right, there is no `--with-python` option to `b2`. 
Sorry for sending you down a wrong route.


I think what you need is described in 
https://www.boost.org/doc/libs/1_74_0/libs/python/doc/html/building/configuring_boost_build.html


Create a ~/user-config.jam file containing the line "using python : 3.7 ;"

This informs Boost.Build of the availability of that Python version 
(depending on your system you may want to add more parameters to specify 
paths, library name, etc.). You could define multiple versions (one per 
line), in which case the option `./b2 python=` will 
allow you to select one.


Hope this helps,

Stefan
--

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python Wrong Python Version macOS

[Stefan Seefeld]

Hi Mortimer,

I'm myself not a Boost.Build expert, and I try to avoid it if ever I can.

But your description sounds as if invoking `./b2` with the option 
`--with-python=3.7` rather than just `--with-python` would work.


(I have no idea what effect those options to `./bootstrap` would have, 
but I assume you can leave them out there, as that merely builds the 
`b2` tool itself.)


Regards,

Stefan
--

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost python] : how to pass a tuple of lists from python to C++

[stefan]

On 2020-02-11 2:05 p.m., HOUSSEN Franck wrote:
OK, I understand this is a type related problem. I found a workaround 
(dummyTest3.py - init numpy arrays with list seems to work).


But, I unfortunately do not get how to change the code to get 
dummyTest2.py to work ?!... Should I read reinterpret_cast'ed data 
sizeof(double) by sizeof(double) : seems cryptic (?!), what's the 
natural way to do that ?


Can't you change your Python code so instead of

  np.append(lsFloat, 1.2)

you would call

  np.append(lsFloat, np.float32(1.2))

to make sure the casting happens before the broadcasting.

(Note: I haven't actually tried that; it just seems the natural fix to 
the issue ;-) )


Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost python] : how to pass a tuple of lists from python to C++

[Stefan Seefeld]

On 2020-02-08 12:07 p.m., HOUSSEN Franck wrote:
I tried to play with extract::check() without much success : line 13 
crashes !?...
This is a very simple exemple : would like to get it to work. Could 
somebody help ? Still googling / searching for a solution


You need to call np::initialize() in your module, i.e. insert

  `np::initialize();`

at the top of your `dummy` module definition.

Stefan
--

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost python] : how to pass a tuple of lists from python to C++

[stefan]

On 2020-02-07 4:06 p.m., HOUSSEN Franck wrote:
With boost python, how to pass a tuple of lists from python to C++ ? 
Code attached : line 12 crashes ?! Googling but no fix for now.


You are referring to this line:

  np::ndarray lsInt = boost::python::extract(t[0]);

Note that this line is actually doing two things:

1) it creates a boost::python::extract object

2) it calls conversion operator on it to convert to np::ndarray

Note that the conversion may fail (for example if the object doesn't 
contain an object of that type). In case of doubt, you may want to call 
extract::check() to see whether it's actually valid.


See 
https://www.boost.org/doc/libs/1_72_0/libs/python/doc/html/reference/to_from_python_type_conversion.html#to_from_python_type_conversion.boost_python_extract_hpp.class_template_extract 
for details.




Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] With boost python tuple, how to loop over tuple items?

[stefan]

On 2020-01-29 4:01 p.m., HOUSSEN Franck wrote:



  With boost python tuple, how to loop over tuple items? In dummy.cpp
  attached, I'd like to get line 8 to work. Afterwards, I noticed line
  7 does not even compile. How to get the length of a tuple (line 8),
  and, why there could be some ambiguity (line 7). Any help / clue is
  appreciated.


Hi Frank,

there are a few minor issues with your code, let me address them 
one-by-one to allow you to compile and run your example:


* you don't need to link your extension module with the Python library. 
Symbols from that library are provided by the interpreter itself. (You 
only need to link to that when you embed the interpreter into your C++ app.)


* you should not call `Py_Initialize()` during your module's 
initialization. Again, that function only needs to be called when you 
embed (and initialize) the interpreter itself.


* use `boost::python::len(t)` to report the length of your tuple

* the call `t[0]` itself is fine, but please be aware that it returns a 
`boost::python::object` instance. You can convert to a (Python) string 
and then extract the C++ string from that using


    std::string s = bpl::extract(bpl::str(t[0]));

and print that.

Hope this helps,

Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Getting the same python instance back in boost::python?

[Stefan Ring]

On Fri, Jun 28, 2019 at 2:16 PM Nicholas Devenish  wrote:
>
> I want to get the same python instance back for subsequent calls to
> the C++ function e.g. I want this to work for the C++ structure below:
>
> import ident_ext
> o = ident_ext.Owner()
> assert o.get() is o.get()
>
> How can I get this behaviour in boost::python? It looked like call
> policies was the right sort of place to look, but can't get that to
> behave how I want. I can get this to work in pybind11 but not boost
> (and unfortunately our project is heavily dependent on boost::python).
> My working c++ is:
>
> #include 
> #include 
> using namespace boost::python;
>
> class Something {
> public:
> void name(void) { std::cout << this << std::endl; }
> };
>
> class Owner {
> Something *_shared = nullptr;
>
> public:
> Something () {
> if (_shared == nullptr) {
> _shared = new Something();
> }
> return *_shared;
> }
> };
>
> BOOST_PYTHON_MODULE(ident_ext) {
> class_("Something").def("name", ::name);
> class_("Owner").def("get", ::get, return_internal_reference<>());
> }

Maybe store a wrapping bp::object in addition to the Something ptr,
then always return the same bp::object? That’s how I did it. Ok, you
would probably have to create a wrapper for Something just for this. I
don’t know how feasible this is.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Getting simple boost.python extension to work outside the test scripts - HELP!

[stefan]

On 2019-05-22 2:30 p.m., Jones, Torrin A (US) wrote:


You may need to set PYTHONPATH.  Search for PYTHONPATH on this page 
for a description.


https://docs.python.org/3/using/cmdline.html

No, PYTHONPATH is used by the Python runtime to locate (Python) modules. 
It is not used to resolve shared library dependencies.


Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Getting simple boost.python extension to work outside the test scripts - HELP!

[stefan]

On 2019-05-22 2:28 p.m., Andrew Voelkel wrote:


That is helpful. It might indeed be an issue with System Integrity 
Protection, now that I do the right google search.


But that leads to the second question. It is possible to indicate 
within hello_ext.so where to look for the dylib. Then in theory this 
wouldn’t a problem, because I wouldn’t need to set DYLD_LIBRARY_PATH.


Is this insertion of the path of libboost_python37.dylib into 
hello_ext.so something I can do with bjam, or am I going to have to 
figure out how to use a separate build system?


I'm cross-posting this to the Boost.Build mailing list, since that's the 
best (only ?) place where you'll get an answer to this question.



Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Getting simple boost.python extension to work outside the test scripts - HELP!

[stefan]

On 2019-05-22 1:55 p.m., Andrew Voelkel wrote:


What magic is the boost environment performing to make this work? What 
can I do to make my python extensions look for libboost_python37.dylib 
in the location where it lives?


Boost.Build does inject a variety of paths into the system-specific path 
variable (I believe on MacOS that would be DYLD_LIBRARY_PATH) such that 
test executables can locate any shared libs they require.


But I also remember having seen cases where some OSX releases 
specifically would prevent that mechanism from working due to some 
security concerns. I'm not a Mac user, so all of this is second-hand 
information.


Best,

Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Python support in boost::python (what version)

[Stefan Seefeld]

On 2019-05-20 11:20 a.m., Jones, Torrin A (US) wrote:


For clarity, my boss is asking, “what version of python does boost 
python support?”  I was hoping there was some kind of table or 
something, but I guess the answer is something like, “It supports 
whatever version of python was out at the time that boost python was 
released?” And then we can go back and look at release dates.  LOL.


What did you expect ? It's obvious that a given release of Boost.Python 
can not make any compatibility guarantees about future Python releases, 
unless, of course, Python itself promises to be fully backward 
compatible. That's precisely why the versioning scheme used by Python 
supports the distinction between "major" and "minor" version, to be able 
to make statements as to what degree of backward-compatibility to expect.


Ex: boost python 1.66.0 was released/tagged on Nov 17, 2017.  Python 
3.6.3 was released on Oct 3, 2017.  Python 3.6.4 was released on Dec 
19. 2017. So in theory boost python 1.66.0 has support for Python 
3.6.3, but does not have support for Python 3.6.4.  I know that’s 
ludicrous but, I work in the corporate world so here we are.



What's your point, exactly ? What are you trying to do ?

(For the specific case, I would *hope* that Boost.Python 1.66.0 was 
compatible with Python 3.6.4, for the reason I cite above. But of 
course, there is no guarantee. Boost is Free Software, and its license 
(https://www.boost.org/users/license.html) clearly states that it is 
provided "...without warranty of any kind...". So make of it what you want.)


Stefan
--

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Python support in boost::python (what version)

[stefan]

On 2019-05-16 3:43 p.m., Jones, Torrin A (US) wrote:


What version of python does boost::python officially support?


Anything above version 2.2

I noticed in the python build file (see link below), it will only find 
from version 1.5 to 3.4.  Does this mean that boost python really only 
supports up to 3.4? Folks do appear to be using other versions, but 
the fact that this only goes to 3.4 leads me to believe that is as far 
as it’s been tested.  Is that right?


Definitely not. You are right, though: this file needs to be fixed. (I'm 
not maintaining this file myself, so I'll follow up with the relevant 
people (Boost.Build).)


Boost internally regularly builds and tests Boost.Python with versions > 
3.4. and I know various distributions containing Boost.Python packages 
built against more recent Python versions.


See for example https://anaconda.org/anaconda/boost/files


What are the official versions? Is there any documentation that says that?

Not really, as Boost only "officially" releases source packages. Users 
are free to compile against a large range of tools and prerequisites 
(compilers, Python versions, etc.).


If you find any issues building and running against a particular Python 
version, please file a bug report, and I'll try to help as quickly as 
possible.



Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Linking issues with Boost.Python 1.69.0, Python 2.7, MSVC 14.0

[Stefan Ring]

On Tue, Mar 26, 2019 at 3:27 PM Sarah Rust  wrote:
>
> Hello!
>
> I have been trying to build and link the latest Boost.Python to work with 
> Python 2.7 and my Visual Studio 2015 project (MSVC 14.0) with x64 
> configuration. I've added the Boost library and Boost include directory to my 
> project's properties, but I am getting the following error when I create a 
> BOOST_PYTHON_MODULE:
>
> error LNK2001: unresolved external symbol "__declspec(dllimport) struct 
> _object * __cdecl boost::python::detail::init_module(char const *,void 
> (__cdecl*)(void))" 
> (__imp_?init_module@detail@python@boost@@YAPEAU_object@@PEBDP6AXXZ@Z)

Have you built Python yourself? With which compiler? Are you linking
against its import lib (for DLL use at run time)? Could you maybe use
the static version of Boost?

Actually while writing this, a though came up: Are you even linking
against the Boost Python library?

> Please let me know how others are doing this.

Probably not at all ;).
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] GSOC

[stefan]

Hi Virali,

On 2019-03-21 3:04 p.m., virali vora wrote:

Hi,
I went through the project details of Boost Python-C++ integeration 
and found them quite interesting.

I would like to contribute to the project.
The project says that we need to implement a c++ interface for Python' 
set type.

So, should that include all the set methods of Python?


Yes.


Also, is there any discussion channel where I can communicate with you?


I'd suggest https://gitter.im/boostorg/python

Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Fail to build Boost Python Tutorial: LNK1120: 55 unresolved externals

[Stefan Ring]

On Tue, Mar 19, 2019 at 3:52 PM Markus Johann Schmidt  wrote:
>  A complete output of my command prompt is attached as well.
>
> May my problem be
>
> wrong import of python library? I try to use a wildcard in lib boost_python 
> instead of `boost_python36-vc140-mt-x64-1_69` But the error stays the same 
> when I rename it
> Some issues with 32bit and 64bit detection?
> Am I missing some imports?

Looks like issues with MSVC's runtime libraries. Maybe rename the
other Visual Studio version's installation directories temporarily to
avoid wrong versions being picked up? I have not tried following the
tutorial myself, though. Have not used Boost on Windows in a decade.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Calling python function repr from C++ using boost.python (possible?)

[Stefan Ring]

On Sat, Mar 2, 2019 at 6:12 PM Jones, Torrin A (US)
 wrote:
>
> Is it possible to call repr from C++ on a C++ object that can be converted to 
> python?  Let me explain.
>
>
>
> I have an enum that I converted to python using boost::python::enum_().  That 
> class already provides a good repr() to python (thanks to the boost::python 
> developers for that).  However that enum is used as a type on a member in 
> another C++ class that I have where boost::python does not provide a good 
> repr().  So I’m trying to provide one and thought, it sure would be nice if I 
> could just call repr() on the member.  I assume I have to convert the value 
> on that member to python first, some kind of way then call repr?  Is that 
> possible?  Or is there a better way?
>
>
>
> Example:
>
>
>
> Typedef enum
>
> {
>
>V1 = 0,
>
>V2 = 5,
>
>V3 = 6
>
> } values;
>
>
>
> Class ValueExample
>
> {
>
>Public:
>
>   ValueExample(const values& v) {m_value = v};
>
>   Values getValue() const { return m_value };
>
>Private:
>
>   Values m_value;
>
> }
>
>
>
> Std::string
>
> ValueExampleRepr(const ValueExample& object)
>
> {
>
>Std::stringstream ss;
>
>
>
>// What do I put here?
>
>// Ss << repr(object.getValue());
>
>
>
>Return ss::str();
>
> }
>
>
>
> Boost::python::enum_ values(“values”);
>
> Values.value(“V1”, V1);
>
> Values.value(“V2”, V2);
>
> Values.value(“V3”, V3);
>
>
>
> Boost::python::class_ ValueExample(“ValueExample”);
>
>
>
> ValueExample(“__repr__”, ValueExampleRepr);

I can only come up with this:

Ss << 
extract(boost::python::object(object.getValue()).attr("__repr__")())();
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [Boost-build] Fwd: Re: Boost 1.69 python3 module

[Stefan Seefeld]

Steven,

I'm not sure the author of the original mail is subscribed to the 
Boost-build list, so I'm cross-posting your reply.


On 2019-02-08 1:56 a.m., Steven Watanabe via Boost-build wrote:

AMDG

On 2/7/19 6:04 PM, Alex Biddulph via Boost-build wrote:




It looks like python was built in that run.
I also noticed:
   project-config.jam:33: syntax error at EOF
which didn't appear in the previous log.
In addition, the new log shows configuration
of python 2.7 instead of python 3.6.

It did indeed appear to build the python library in that case (although I 
missed a semicolon so it built python27 instead of python36).

I corrected my error (also scrubbing the build folder again), and this time it 
correctly built and installed the python36 library.
Here is the link to the output for this build
https://drive.google.com/open?id=1UHzlwMfAlXlOEghqIFH41jnBlfPNAH51


Well, at least you now have a workaround.


So I went back to building everything (I left the --debug-building option on) 
and once again, it built everything but the python36 library. Here is the link 
to the build output for this build
https://drive.google.com/open?id=14m9Jrwz8imrEi90HGkkmglVKEI3v6FHH


That's really strange.  I have no idea why that would happen.
There's definitely some kind of hidden global state somewhere.
That mostly confirms my suspicion that the offending rule is
python.require-py.  Maybe if you add /debug/ into the call to
main-target.select-alternatives, it will reveal something:

 local py-ext-alternative = [ $(py-ext-target).select-alternatives
$(property-set) debug ] ;

In Christ,
Steven Watanabe
___
Unsubscribe & other changes: 
https://lists.boost.org/mailman/listinfo.cgi/boost-build

--

Stefan
--

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [Boost-build] Boost 1.69 python3 module

[stefan]

Alexander,

I'm replying by re-adding some addresses, just so you don't miss 
Steven's reply below. Can you please try that and report back what you get ?


On 2019-02-06 12:13 p.m., Steven Watanabe via Boost-build wrote:

AMDG

On 2/6/19 7:22 AM, stefan via Boost-build wrote:

On 2019-02-04 8:54 p.m., Alexander Biddulph wrote:

Hi,

Finally managed to get around to rebuilding this with "-d2" added to
the command line. Here is a link to the build output
https://drive.google.com/open?id=1tlwj3-uGd6wsZ5qJcrD4Ms4RbaVMbDmC

As before, everything seems to be built and installed, except for the
python library.
As before, Boost.Build seems to find the python installation and says
it is going to build the python library, but just doesn't seem to get
around to doing it and there don't appear to be any errors that the
build system encountered.


I don't see anything obvious either. Steve, can you help with this ?


Try `--with-python --debug-building`  (--debug-building
generates way too much output if you build everything)
I suspect that you'll see "no in common properties"
My best guess is that the problem is in python.require-py.
Maybe run under the debugger and set a breakpoint there.

In Christ,
Steven Watanabe
___
Unsubscribe & other changes: 
https://lists.boost.org/mailman/listinfo.cgi/boost-build


Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost 1.69 python3 module

[stefan]

On 2019-02-04 8:54 p.m., Alexander Biddulph wrote:


Hi,

Finally managed to get around to rebuilding this with "-d2" added to 
the command line. Here is a link to the build output

https://drive.google.com/open?id=1tlwj3-uGd6wsZ5qJcrD4Ms4RbaVMbDmC

As before, everything seems to be built and installed, except for the 
python library.
As before, Boost.Build seems to find the python installation and says 
it is going to build the python library, but just doesn't seem to get 
around to doing it and there don't appear to be any errors that the 
build system encountered.



I don't see anything obvious either. Steve, can you help with this ?

Thanks,


Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost 1.69 python3 module

[stefan]

Hi Alexander,


On 2019-01-28 9:02 p.m., Alexander Biddulph wrote:


Hopefully this is the right list for this.



It is, though the issue may be more related to the Boost build system 
(b2 / Boost.Build), so I'm cross-posting to try to get their attention, too.





I have been struggling to get Boost 1.69 to build Boost.Python against 
Python 3.6.3.


I have specified the location of the python binary, include, and 
library (due to a non-standard install location) in the 
project-config.jam file in the Boost source directory.


Running bjam and specifying  "--debug-configuration" results in 
"[python-cfg]" output indicating that boost has found my Python 
installation and is satisfied with it configuration, it also indicates 
that it found numpy.


notice: [python-cfg] Configuring python...
notice: [python-cfg]   user-specified version: "3.6"
notice: [python-cfg]   user-specified cmd-or-prefix: "/nubots/toolchain"
notice: [python-cfg] Checking interpreter command 
"/nubots/toolchain/bin/python3.6"...
notice: [python-cfg] running command '/nubots/toolchain/bin/python3.6 
-c "from sys import *; 
print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' 
% 
(version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 
2>&1'

notice: [python-cfg] ...requested configuration matched!
notice: [python-cfg] Details of this Python configuration:
notice: [python-cfg]   interpreter command: 
"/nubots/toolchain/bin/python3.6"

notice: [python-cfg]   include path: "/nubots/toolchain/include/python3.6"
notice: [python-cfg]   library path: 
"/nubots/toolchain/lib/python3.6/config" "/nubots/toolchain/lib"

notice: [python-cfg] Checking for NumPy...
notice: [python-cfg] running command '/nubots/toolchain/bin/python3.6 
-c "import sys; sys.stderr = sys.stdout; import numpy; 
print(numpy.get_include())"'

notice: [python-cfg] NumPy enabled
notice: [python-cfg] Configuring python...
notice: [python-cfg]   user-specified version: "3.6"
notice: [python-cfg]   user-specified cmd-or-prefix: 
"/nubots/toolchain/bin/python3"
notice: [python-cfg]   user-specified includes: 
"/nubots/toolchain/include/python3.6m"

notice: [python-cfg]   user-specified libraries: "/nubots/toolchain/lib"
notice: [python-cfg] Details of this Python configuration:
notice: [python-cfg]   interpreter command: 
"/nubots/toolchain/bin/python3"
notice: [python-cfg]   include path: 
"/nubots/toolchain/include/python3.6m"

notice: [python-cfg]   library path: "/nubots/toolchain/lib"
notice: [python-cfg] Checking for NumPy...
notice: [python-cfg] running command '/nubots/toolchain/bin/python3 -c 
"import sys; sys.stderr = sys.stdout; import numpy; 
print(numpy.get_include())"'

notice: [python-cfg] NumPy enabled

During the component configuration output it says "- python            
       : building".



OK, so far all looks good / expected.




Scanning through the build output there are numerous lines where 
boost.python header files are copied (lines starting with 
common.copy). However, the libboost_python appears to never be built 
or installed and there is no output indicating that there was an error 
with any stage of the build.



Can you please attach the full output of your build ? (Perhaps even 
rerun with `-d2` to make the output more verbose ?)





It looks as though all other Boost modules/libraries are built, just 
not Boost.Python. What is going on here?



Thanks,



Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] distributing libraries built using Boost.Python

[Stefan Seefeld]

Hi Danielle,


On 2018-10-16 11:41 AM, danielle amethyst brake wrote:

Hi Boost.Python friends,

I have a library, which consists foremostly of a set of bindings built 
using Boost.Python, and I am finding distribution to be a barrier.  
Requiring the user to build themselves prevents most of my users from, 
well, being users. Hence, I am writing today to query about 
best-practices and ideas on how to distribute my Python library, that 
consists of pure Python code installable via pip, a built .so library, 
and an underlying .so/.a/.dyld/whatever core library also built from C++.


the biggest issue really is ABI compatibility, i.e. you can't simply 
distribute a C++ library such as Boost.Python compiled with one 
compiler, and expect it to work in machines with arbitrary other 
compilers (or compiler versions). Once the set of supported compilers / 
compiler versions is settled, it's much easier to share binaries.


If you are mainly working with Python, i.e. if your C++ code is only 
used in extension modules, you may consider using Anaconda, which 
provides some structure in its package management that could help you 
and your users.


Cordially,

Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost python undef symbols

[Stefan Seefeld]

On 07/13/18 08:41, Servando Arboli wrote:
>
> Dear all,
>
> I’m trying to install boost python in Windows but I must be doing
> something wrong. The execution of b2 with python has produced a
> library, but when I’m trying to link I get errors related to undefined
> symbols.
>
>  
>
> I’ve done a dumpbin /symbols with the library generated by b2,
> filtering the undef symbols, I get plenty of them:
>

[...]

Of course. Your code (as well as Boost.Python) is using symbols provided
by other libraries, including the standard C++ library (which provides
operator new and delete), and the Python library itself (which provides
all the symbols starting with `__impl_Py`), so you need to make sure
those libraries are linked to in your command-line.



Stefan

-- 

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to derive a python class from a C++ base abstract class [Boost.python]

[Stefan Seefeld]

On 2018-07-10 03:55 PM, Danny C wrote:

Hi,

I am trying to build a hybrid system for exposing my C++ library to 
python and some other languages.


Use case:
Expose certain C++ abstract classes to be extended in python. A 
different exposed concrete class instance uses the methods from 
extended classes as callbacks



Q1: I want to derive a python class whose base class is an ABSTRACT 
class written in C++. How do I do this. I've read many threads and 
similar questions but most of them are concerning SWIG. I want to use 
boost.python for my purpose. Any help on this is really appreciated.


Q2: How do I implement callbacks from C++  to python i.e. my callback 
function is written in python.


Have you read the docs 
(http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html#tutorial.exposing.class_virtual_functions) 
?


Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] bjam invocation error "rule copyright unknown in module man"

[Stefan Seefeld]

On 2018-05-04 12:47 PM, Everest Chen wrote:

Hi all,

I m following the non-install quickstart guide for a ubuntu 16.04, I 
had problem at basic procedure step 4 
https://www.boost.org/doc/libs/1_66_0/libs/python/doc/html/building/no_install_quickstart.html


the command is
/example/tutorial$ bjam --debug-configuration

then the msg is
notice: found boost-build.jam at 
/home/everest/Downloads/boost_1_67_0/boost-build.jam
notice: loading Boost.Build from 
/home/everest/Downloads/boost_1_67_0/tools/build/src
/home/everest/Downloads/boost_1_67_0/tools/build/src/tools/types/man.jam:8: 
in load

ERROR: rule "Copyright" unknown in module "man".

How to fix this? Thanks.


I forwarded the question to the Boost.Build maling list. Rene Rivera 
replied:


It's using an old, probably system installed, b2 executable. You need 
to use the b2 from the current boost distribution.



Stefan

--

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


___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost.Python and Python limited API

[Stefan Seefeld]

On 09.10.2017 16:44, Jason Patton wrote:
> Apologies on resurrecting a 7.5 year old topic (
> https://mail.python.org/pipermail/cplusplus-sig/2010-March/015390.html
> ) but does anyone else have experience with building Boost.Python with
> the limited API (see: https://docs.python.org/3/c-api/stable.html and
> https://www.python.org/dev/peps/pep-0384/ )? My experience suggests
> that Boost.Python is not compatible, but I'd like to make sure that
> I'm not missing something with my build process:

[...]

I'm not sure what you mean by "compatible", but indeed, Boost.Python
right now doesn't provide a build variant that generates bindings for
that stable ABI/API.
That being said, I'd be happy to assist anyone who wants to work on
patches towards that goal, if there is enough interest. Please open an
issue on https://github.com/boostorg/python/issues so we can discuss
details.

Regards,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Overloading methods in derived class

[Stefan Ring]

On Thu, Aug 17, 2017 at 12:32 AM, Jeremy Mayes  wrote:
> File “.../test.py”, line 11, in 
> b.foo(0)
> Boost.Python.ArgumentError: Python argument types in
> B.foo(B, int)
> Did not match C++ signature:
> foo(B {Value}, int, double)
>
> I’m not surprised by this behavior given python’s method resolution process.
> My question is whether there’s a good way to deal with this in boost.python
> so that I don’t have to add duplicate entries in sub-classes for methods
> I’ve already exposed in base classes.

Would you not have to declare the overloaded methods even if they were
all part of the same class? It might even work exactly the same way,
if the overloaded methods from the base class are not hidden.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to get output from python embedded in VC++

[Stefan Seefeld]

On 23.07.2017 03:15, Jian wrote:
>
> Hi Stefan,
>
> I still got a assertion failed at Py_Initialize(). Below is the message.
>
> Program: C:\Python35\python35_d.dll
> File: ..\Objects\object.c
> Line: 84
> Expression: (op->_ob_prev == NULL) == (op->_ob_next == NULL)

And you get this output from the Py_Initialize() call itself ?? I have
no idea how this could happen. I have very little experience with
Windows, and so am not really able to help debug this. My first guess
would be that you are linking to the wrong library. (I see
'python35_d.dll'. What happens if you link to 'python35.dll', i.e. the
non-debug version ?)

>
> I also pasted mo code below. This function is invoked by a button
> click function. No other codes around it.
>
> int runBoostPython()
> {
> Py_Initialize();
> try {
> //boost::python::object main_module =
> //boost::python::import("__main__");
> //boost::python::object main_namespace =
> //main_module.attr("__dict__");
> boost::python::dict main_namespace;
>
> boost::python::object ignored = exec_file("test1.py",
> main_namespace, main_namespace);
>
> std::wstring output =
> boost::python::extract(main_namespace["return_value"]);

I'm not sure it's possible to use `extract` with std::wstring. At least
I have never used it with that. (What encoding is your string using ?
How should it be converted to a wide string ?)


>
> }
> catch (boost::python::error_already_set) {
> PyErr_Print();
> }
> return 0;
> }
>
> Please help check it. 
>
> Thanks & Best Regards,
>
> John.

Regards,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to get output from python embedded in VC++

[Stefan Seefeld]

On 21.07.2017 23:17, Jian wrote:
> Hi Imre,
>
> I tried to use boost.python as you advised. Build boost.python with 
>
> But I got a error in the import.hpp as below:
> import.hpp start
> 
> namespace boost 
> { 
> namespace python 
> {
>
> object BOOST_PYTHON_DECL import(str name)
> {
>   // should be 'char const *' but older python versions don't use
> 'const' yet.
>   char *n = python::extract(name);
> *  python::handle<> module(PyImport_ImportModule(n));   <---here is
> where the error raised. n is "__main__"*
>   return python::object(module);
> }
>
> }  // namespace boost::python
> }  // namespace boost
> import.hpp
> end
>
> I copied your code and just replaced 'script.py' with the name of my
> own file. I found the error raised when the code importing module
> "__main__". 
>
> That's my first time to use boost.python. Could you help about this issue?

This probably means you haven't initialized Python correctly. A good
starting point might be this example:
https://github.com/boostorg/python/blob/develop/example/quickstart/embedding.cpp

(I'm the Boost.Python maintainer. While I'd be happy to help you using
Boost.Python, I think this is mostly orthogonal to your original
question about how to capture output generated by you embedded Python.)



Best,
Stefan




-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to get output from python embedded in VC++

[Stefan Seefeld]

On 21.07.2017 10:03, Jian wrote:
>
> Then, I have tried this method. It works. I got the text print from
> the file. below are the code I used following your advice.
>
> import sys
> original = sys.stdout
> sys.stdout = open('redirect.txt', 'w')
> ...
> other code!
> ...
> sys.stdout.close()
> sys.stdout = original
>
> But it still not exactly what I expected. Because the text printed to
> the file can't be read into the program at the same time.

Then don't redirect to a file; redirect to a buffer that you can attach
to your text output widget. The object assigned to `sys.stdout` doesn't
have to be a file, it only needs to be a "file-like" object. So,
typically you'd use something like StringIO, or, as is done by the
document I pointed you to, a GUI widget directly (see section
"Redirecting stdout in wxPython").

>
> As you mentioned you are not familiar with Windows. I guess you are
> using Linux. So could you give me some advice if it can be done in
> C/C++ in Linux?

See above. The problem is entirely unrelated to the platform you are
running on. I was just commenting on the approach you had taken, which
was Windows-specific.

>
> Thanks again for your kind help.
> Best Regards,
>
> Jian

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to get output from python embedded in VC++

[Stefan Seefeld]

On 19.07.2017 23:25, Jian wrote:
>
> Dear Gurus,
>
> I want to embed python interpreter in my program. What I want is to
> redirect those output to a control such as RICHEDIT which can be
> modified as a output window in my program. So I can write *.py files
> outside of program and invoke it inside program as a script file. In
> order to get information output by the *.py file I need to get the
> stdin I have tried some workflow but not perfect.
>

So you want to capture all output produced by the Python session,
without changing the behaviour of `std::cout` or `printf()`, correct ?

> 1). I have tried use Allocconsle(). But I can only get the output info
> printed by std::out & printf() in the current code. all things which
> are printed by python35.dll are missing. I used print('') in the
> *.py file to test the output. Those *.py files are OK in command line
> mode.
>
> 2). I also tried to derive class basic_streambuf and overwrite the
> in/out functions. It works only for output from std::out. Text from
> printf() as well as from dlls are missing.
>
> 3). then I tried to use linker settings as below.
>
> #pragma comment( linker, "/subsystem:console /entry:wWinMainCRTStartup" )
>
> A cmd window is created along with the program. everything output from
> current process and dlls are retrieved successfully as I want. But the
> cmd window is not easy to control.
>
> Is there a better way for this purpose?
>

I suggest you import the `sys` module and substitute `sys.stdout` and
`sys.stderr` to capture output rather than send to stdout and stderr.
The technique is described in many places, for example
https://www.blog.pythonlibrary.org/2016/06/16/python-101-redirecting-stdout/.
Please be aware that due to the way Python3 changed its representation
of strings (, unicode, bytes, etc.) you may have to be careful to find a
solution that works portably.

You could do this either in a Python wrapper script, or directly in the
code you use to initialize your Python session (in C++).

I'm only a casual Windows user (and even less programmer), so can't
comment on any Windows-specific idioms to use.

HTH,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Is there anybody has idea about access the set from python?

[Stefan Seefeld]

On 19.01.2017 19:48, 奇真亦假 wrote:
> Thank you very much. You really do me a lot.
>
> As I know, it seems that boost::python::set has missed for several years.

Right. I'll see whether I can add it for the next release. (Note,
though, that this is only a convenience interface. There is nothing you
can't already do using the boost::python::object interface. It's just a
bit more concise to have a dedicated high-level wrapper type for 'set'.)

    Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Is there anybody has idea about access the set from python?

[Stefan Seefeld]

On 18.01.2017 23:04, 奇真亦假 wrote:
> It's strange that boost::python don't support boost::python::set.

Indeed, a wrapper type for that is missing. Feel free to submit a patch.

> Set is a very usable structure, so is there any idea about it? How to
> convert a python::set to a std::set or any other hash-able structure?

Converting python sets to C++ should be done by custom converters, as I
doubt there is  a single way to do it that would meet everyone's
requirement.

> Btw, how about boost::python::dict's performance? Does it implemented
> by hash-table?

All boost::python object types are thin wrappers around their Python
counterparts, i.e. a boost::python::dict simply wraps a Python dict.
See
http://boostorg.github.io/python/doc/html/tutorial/tutorial/object.html#tutorial.object.derived_object_types

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

[C++-sig] Boost.Python NumPy extension

[Stefan Seefeld]

Hello,

I'm happy to announce that I just merged the NumPy C++ wrappers from
https://github.com/ndarray/Boost.NumPy into Boost.Python's development
branch. (Online documentation for it can be browsed here:
http://boostorg.github.io/python/develop/doc/html/numpy)

I'd very much like to be able to merge this into the master branch for
the next Boost release (version 1.63).
At present I'm using SCons to build Boost.Python (stand-alone, against a
separately installed Boost), which is also the infrastructure I use for
CI testing (https://travis-ci.org/boostorg/python).

I would like to ask for help with integrating the new NumPy extension
into the Boost.Build-based build system, such that this will also be
picked up by the regular Boost infrastructure. Please refer to
https://github.com/boostorg/python/issues/89 if you'd like to help with
this.

Many thanks !

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python. access pandas columns in the same order as in python

[Stefan Seefeld]

On 04.10.2016 09:05, Vladimir Sakharuk wrote:
>
> Hello All,
>
>
> Trying to figure out how to c++ access pandas dataframe columns in the
> same order as they exist in the python.
>
> in python:
>

[...]

> ||
> |//outputs regardless of original order of column names.   
> //index=0, colname=AAA//index=1, colname=BBB//index=2,
> colname=CCC|
>
> As you can see pythons' order 'CCC','BBB','AAA' is not same as c++
> 'AAA', 'BBB', 'CCC'. Looks like those order depend on object hasing.
>
>
> How could I get those values in the original order of pandas dataframe
> from C++?
>

I can't reproduce that; I see the same order (['CCC', 'BBB', 'AAA'])
both in Python and in C++ with your code above.

FWIW,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute

[Stefan Seefeld]

On 09.09.2016 09:29, Jon Lederman wrote:
> Hi,
>
> Thanks for the response.  However, this example doesn’t work for me either if 
> I set the shared object file to zoo.so.  It doesn’t find the animal attribute:
>
> http://pyengr.readthedocs.io/en/latest/inter/bpy
>
> Can you explain why?

It's impossible to help you with so few details. Please describe
*exactly* what you are doing. As I suggested already, the easiest thing
is to come up with a minimal self-contained test case, then describe in
detail how you compile it (what platform, what compiler command, etc.)
so we can attempt to reproduce your observations.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute

[Stefan Seefeld]

Hi Jon,

please remove the dependency on the "opus/*" headers, so we can compile
the module ourselves and try to reproduce what you are reporting.
(That's what I meant with "self-contained test".)


Thanks,
Stefan

On 08.09.2016 17:30, Jon Lederman wrote:
> Hi,
>
> Thanks for responding.  Here is my header file.  I am compiling this to a 
> shared object called opus_strategy.so.  If I set the argument of 
> BOOST_PYTHON_MODULE to opus_encoder_strategy, and compile my .so file to have 
> the name opus_encoder_strategy.so,I can load the boost python module into my 
> python interpreter and see the OpusEncoderStrategy class as an attribute.  
>
> However, if I choose other names such as opus_strategy for the argument to 
> BOOST_PYTHON_MODULE, when I load the boost python object it doesn’t appear to 
> have any recognized attributes.  I don’t understand why the name should 
> matter.  As I had noted in my previous email, I would like to have a shared 
> object file with the name opus_strategy.so that encompasses a set of classes. 
>  Just can’t figure out how to get it to work.  I am on OS X, BTW if that 
> matters.   
>
> Any help would be greatly appreciated.
>
> Thanks.
>
> -Jon
> #ifndef OPUS_ENCODER_STRATEGY_H_
> #define OPUS_ENCODER_STRATEGY_H_
>
>
>
>
>
> #include "memory"
> #include "opus/opus.h"
> #include "opus/opus_defines.h"
> #include "opus/opus_multistream.h"
> #include "opus/opus_types.h"
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> namespace bp = boost::python;
> namespace np = boost::numpy;
>
> using namespace std;
>
>
> class OpusEncoderStrategy {
>
> public:
>
>   OpusEncoderStrategy(const int sample_rate, const int number_channels, 
> const int opus_application);
>   ~OpusEncoderStrategy();
>
>   opus_int32 encode(const float* pcm, const int frame_size, const 
> unsigned char* data,  opus_int32 max_data_bytes);
>
>   bool setComplexity(const int c);
>   int getComplexity();
>
>
> private:
>
>   bool encoderCtl();
>   int getPacketDurationBytes();
>
>   
>
>   OpusEncoder* encoder;
>
>   int fs;
>   int channels;
>   int application;
>   int error;
>
>
> };
>
>
> BOOST_PYTHON_MODULE(opus_strategy)
> {
>   using namespace boost::python;
>
>
>   class_("OpusEncoderStrategy", init const int, const int>())
>   .def("setComplexity", ::setComplexity)
>   .def("getComplexity", ::getComplexity);
> }
>
>
> #endif
>> On Sep 8, 2016, at 4:47 PM, Stefan Seefeld <ste...@seefeld.name> wrote:
>>
>> Hi Jon,
>>
>> what you are describing makes perfect sense, and should work without
>> problem. From your description it isn't clear why this isn't working, so
>> I suggest you put together a self-contained test that doesn't work as
>> you expect, and send that out so we can have a look. Otherwise we'd have
>> to guess.
>> The online docs at http://boostorg.github.io/python/doc/html/index.html
>> should contain everything you need.
>>
>>Stefan
>>
>> -- 
>>
>>  ...ich hab' noch einen Koffer in Berlin...
>>
>> ___
>> Cplusplus-sig mailing list
>> Cplusplus-sig@python.org
>> https://mail.python.org/mailman/listinfo/cplusplus-sig
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python Question - Multiple Classes and Modules not appearing as attribute

[Stefan Seefeld]

Hi Jon,

what you are describing makes perfect sense, and should work without
problem. From your description it isn't clear why this isn't working, so
I suggest you put together a self-contained test that doesn't work as
you expect, and send that out so we can have a look. Otherwise we'd have
to guess.
The online docs at http://boostorg.github.io/python/doc/html/index.html
should contain everything you need.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Segmentation Fault (core dumped) on Python 3.5.2 but not Python 2.7.12

[Stefan Seefeld]

Hi Matthew,

would you mind submitting an issue on
https://github.com/boostorg/python/issues for this.

Thanks,
Stefan

On 04.08.2016 13:10, Matthew Conte wrote:
> So I'm trying to create a boost python module that simply creates and
> returns a numpy array, 
> but the function crashes (sometimes) and it doesn't ever seem to crash
> on Python 2.
>
> Here's the source code I made:
>
> #include 
> #include 
>
> using namespace boost::python;
>
> object create_numpy_array() {
> npy_intp dims = 1;
> long* data = new long[1];
> data[0] = 1;
> PyObject* obj = PyArray_SimpleNewFromData(1, , PyArray_LONGLTR,
> data);
> boost::python::handle<> handle(obj);
> boost::python::numeric::array arr(handle);
> return arr.copy();
> }
>
> BOOST_PYTHON_MODULE(create) {
> import_array();
> numeric::array::set_module_and_type("numpy", "ndarray");
> def("numpy_array", _numpy_array);
> }
>
>
> using a simple python script to test:
>
> import create
> print(create.numpy_array())
>
>
> The stack trace indicates that the crash occurs on a
> boost::python::handle destructor trying to decrease the ref count of a
> PyObject with a ref count of 0.
>
> I've tried this on both Windows 7 and Ubuntu 16.04 both 64-bit.
>
> Thank you.
>
>
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Testing build of Boost.Python

[Stefan Seefeld]

Hi Stephen,


On 15.07.2016 16:18, Stephen Wang wrote:
> Hello all,
>
> I have built the Boost.Python libraries with the following options &
> configs:
>
> *bjam ^
>  variant=debug,release ^
>  link=static,shared ^
> runtime-link=shared --debug-configuration ^
> architecture=x86 address-model=64 ^
> runtime-debugging=on,off ^
> --with-python*
>
> I am testing the build.  When I execute
> *
> C:\Users\swang10\boost_1_61_0\libs\python\example\quickstart>bjam test
> --verbose-test*
>
> I get a fatal link error that python35_d.lib cannot be found.  Any
> ideas of a workaround?

It sounds like you are missing a debug version of the Python library.
http://stackoverflow.com/questions/35250175/i-cannot-find-python35-d-lib
might be of help.

Best,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Issue Overriding C++ virtual methods in boost python for use in other C++ functions

[Stefan Seefeld]

Hi Liam,

On 08.07.2016 15:58, Liam Herron wrote:
>
> ##
>
> # THIS DOESN'T WORK
>
> ##
>
>  
>
> class MyPySmoothFunction(PyWrapSmoothFunction):
>
>def __init__(self):
>
>   pass
>

You need to initialize the base class. For example:

   def __init__(self):
  super(MyPySmoothFunction, self).__init__()


Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] building boost with custom python 3.5 installation

[Stefan Seefeld]

Hi Kovas,

I suggest you send your question to the boost mailing list, where people
with boost.build expertise may be able to help you.

I have myself lost track of boost.build, and have therefore added a
parallel build system using SCons. Using that you can build boost.python
as a stand-alone library, against a pre-installed boost.
With that you specify the python version to use via `scons config
--python=` from which all other flags will be
deduced.
This is right now available in the 'develop' branch in
https://github.com/boostorg/python, and should be merged into master in
time for the next release.

HTH,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Stand-alone Boost.Python

[Stefan Seefeld]

On 20.06.2016 04:35, Giuseppe Corbelli wrote:
> On Sat, 18 Jun 2016 00:25:08 -0400 Stefan Seefeld <ste...@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...

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Getting Boost.Python to explain itself better?

[Stefan Seefeld]

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...

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

[C++-sig] Stand-alone Boost.Python

[Stefan Seefeld]

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...

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Multiple registration safety and unit testing

[Stefan Seefeld]

Hi David,

I'm just reviewing Boost.Python PRs, and looking at
https://github.com/boostorg/python/pull/55 I was reminded of this little
exchange.
Sorry for having dropped the ball here...

On 01.02.2016 17:36, David Sankel wrote:
> On Sat, Jan 30, 2016 at 7:30 AM, Stefan Seefeld <ste...@seefeld.name
> <mailto:ste...@seefeld.name>> wrote:
>
>
> Yes. Can you describe your use-case ? And what do you mean exactly by
> "semantically different" ? :-)
>
>
> In one '.cpp' file I have something like:
>
>
> void addFooAssets()
> {
>   boost::python::class_< Foo > ( /* etc. */ )
> .def( /* etc */ );
> }
>
> // testing code follows.
>
> BOOST_PYTHON_MODULE( fooTest )
> {
>   addFooAssets();
> }
>
> BOOST_AUTO_TEST_CASE( fooAssets ) {
>   // import 'fooTest' and check that all is good.
> }
>
> In another '.cpp' file, I have something like:
>
> void initBarPackage()
> {
>   boost::python::object barPackage = boost::python::scope();
>   barPackage.attr( "__path__" ) = "bar";
>
>   boost::python::object barFooPackage(
> boost::python::handle<>(
> boost::python::borrowed(::PyImport_AddModule( "bar.foo" ) ) ) );
>   barPackage.attr( "foo" ) = barFooPackage;
>
>   {
> const boost::python::scope fooScope( barFooPackage );
> addFooAssets();
>   }
> }
>
> // testing code follows
>

What do you attempt to do in the above ? Why not simply create "bar" via
BOOST_PYTHON_MODULE(bar) ? For example:

BOOST_PYTHON_MODULE(bar)
{
  object barPackage = scope();
  object barFooPackage = import("foo");
  barPackage.attr( "foo" ) = barFooPackage;
}

should have the effect you are seeking, if I understand correctly. There
is no need to invoke "addFooAssets()" twice.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Trouble building boost with Visual Studio 2010

[Stefan Seefeld]

Hi David,

On 09.03.2016 05:04, David Aldrich wrote:
>
> Hi
>
>  
>
> I am trying to build Boost 1.60 with Visual Studio 2010 Professional
> on Windows 10.
>
>  
>
> I use the command:
>
>  
>
> b2 toolset=msvc-10.0 --with-python link=shared
>
>  
>
> and get the following error:
>
>  
>
> python34.lib(python34.dll) : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'X86'
>

Just a quick guess: is it possible that your "libpython34.dll" file is a
64-bit binary, when the command really requires it to be a 32-bit binary ?

>  
>
> I guess this means I have a conflict of 32-bit and 64-bit libraries. 
> I want to target 32-bit (X86).
>
>  
>
> Do I need to install a 32-bit version of Python?  I wonder if that can
> co-exist with the current version of Python?
>

I'm unfortunately unable to answer your question, as the question seems
more about the build system than Boost.Python itself.
Therefore I'm including the Boost mailing list in my reply, hoping that
some Boost.Build expert may be able to help.

Regards,
Stefan



>  
>
> Best regards
>
>  
>
> David
>
>  
>
>
>
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Problem with and fix for automatic pointer registration in Boost.Python 1.60

[Stefan Seefeld]

On 04.03.2016 13:45, Greg Falcon via Cplusplus-sig wrote:
> Boost.Python 1.60 has a bug, introducing an incompatibility from 1.59,
> and first noted on this mailing list on January 11.  What has changed
> is that a class declaration of the form
>
>   class_<Foo, shared_ptr>("Foo");
>
> will no longer automatically register a converter for the shared_ptr
> wrapper.
>
> This is not an intentional change, but a bug exposed by a change to
> Boost.MPL.  The template metaprogramming in class_metadata.hpp makes
> assumptions about the types used in Boost.MPL that are no longer true.
>
> I have posted a fix to this issue
> at https://github.com/boostorg/python/pull/59/files, which at least
> solves the problem for us.  This patch, when applied against 1.60,
> fixes pointer registration.  It can also be applied to 1.59 without issue.
>
> If someone on this list could take a look at this change, I'd
> appreciate it.  Let me know if you have any questions.

I have merged the PR, and will try to get it into master for the 1.61
release. Sorry this took so long.
Stefan


>
> Thanks,
> Greg Falcon
>
>
>
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] calling python object's method from c++

[Stefan Seefeld]

On 19.02.2016 08:10, Sampsa Riikonen wrote:
> Dear List,
>
> I am unable to solve an issue with the python c api (python 2.7).
>
> Namely, I am trying to pass a python object to c++, where the python
> object is then passed to a c++ class that calls the python object's
> method.. I only get segmentation faults.
>
> No one has been able to help with me with this problem, so I thought
> that a guru from this mailing list / community might know the answer.
>
> The question, with setup.py, source code, etc. has been posted here:
>
> http://stackoverflow.com/questions/35466991/calling-python-objects-method-from-c
>
>
> .. it is a few-liner, testing the concept of passing around python
> objects within c++.

Hi Sampsa,

there are many stylistic issues with your code, and solving those would
make the bug obvious. The bug is really in your testclass constructor:

  testclass(int* i, PyObject* po) {
std::cerr << "testclass constructor! \n";
i=i; po=po;
  }

You think you are assigning the two arguments 'i' and 'po' to the two
member variables 'i', 'po', but you are not. You are assigning the
variables to themselves. (The compiler may even chose to optimize away
these as no-ops !)


I don't know swig, but for rich mapping between Python and C++ I would
suggest you consider Boost.Python, which is way more powerful.


Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Multiple registration safety and unit testing

[Stefan Seefeld]

On 29.01.2016 19:19, David Sankel wrote:
> Hello all,
>
> I'd like to allow a class to be registered more than once and wanted
> to get your opinion if this change would be a good idea.
>
> 'boost::python::class_' always adds a class to the current scope and
> registers it in the global registry. The global registry code
> (particularly the 'insert' function in 'src/converter/registry.cpp')
> asserts that the class hasn't been registered already. This, of
> course, prevents multiple registrations of the same type.
>
> There is a use case, though, where multiple registrations of the same
> type is both necessary and safe. Generally, a c++ component which has
> a 'class_' call may not know the name of the module it will eventually
> end up in. It would still be desirable to write a unit test for this
> component. If we write a unit test and put the 'class_' into some
> dummy module we run into a problem where other unit tests might call
> 'class_' in another scope.
>
> The safety of multiple 'class_' calls stems from always using the same
> conversion function. Semantically everything is a-okay.
>
> I'm proposing to change the precondition of the
> 'boost::python::converter::registry::insert' function from:
>
> The behavior is undefined unless the specified 'type_info' object
> has not already been registered.
>
>
> to:
>
> The behavior is undefined unless the specified 'type_info' object
> has not already been registered with a semantically different
> converter
>
> Any objections?

Yes. Can you describe your use-case ? And what do you mean exactly by
"semantically different" ? :-)

Thanks,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] passing NoneType as argument to constructor

[Stefan Seefeld]

On 29.01.2016 13:15, Liam Herron wrote:
>
> For the following code:
>
> ---
>
> #include 
>
> using namespace boost::python;
>
>  
>
> namespace // unnamed
>
> {
>
>  
>
> class NullableDouble
>
> {
>
> public:
>
>NullableDouble()
>
>   : isNull_(true)
>
>   , value_(0.0)
>
>{
>
>}
>
>  
>
>NullableDouble(double x)
>
>   : isNull_(false)
>
>   , value_(x)
>
>{
>
>}
>
>  
>
>double value() const
>
>{
>
>   return value_;  // null check not relevant to this example
>
>}
>
>  
>
>bool isNull() const
>
>{
>
>   return isNull_;
>
>}
>
>  
>
>// ... more functions but not needed for this example
>
>  
>
> private:
>
>bool isNull_;
>
>double value_;
>
> };
>
>  
>
> } // end namespace unnamed
>
>  
>
> void init_pnic()
>
> {
>
>class_
>
>("NullableDouble", "NullableDouble", init<>())
>
>   .def(init())
>
>   .def("value", ::value)
>
>   .def("isNull", ::isNull)
>
>;
>
> }
>
>  
>
> BOOST_PYTHON_MODULE(_testPNIC)
>
> {
>
>init_pnic();
>
> }
>
> ---
>
>  
>
> I would like to have another constructor method in python that takes a
> ‘None’ and returns the same as the no arg constructor ‘NullableDouble()’
>

Just create a 'factory' function that takes a Python object (and which
you then check for None) to instantiate and return a "null". Add that
function to your wrapper like any other method (using '__init__' and
'make_constructor').

HTH,
Stefan




>  
>
> What is the best way to do this?
>
>  
>
> Thanks,
>
> --Liam
>
>  
>
>  
>

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Passing memory allocated in C++ to Python

[Stefan Seefeld]

On 12.01.2016 12:52, Tony Cappellini wrote:
>
> Stefan,
>
>
> To: cplusplus-sig@python.org <mailto:cplusplus-sig@python.org>
> Subject: Re: [C++-sig] Passing memory allocated in C++ to Python
> Message-ID: <56945036.8080...@seefeld.name
> <mailto:56945036.8080...@seefeld.name>>
> Content-Type: text/plain; charset=windows-1252
>
> > Essentially- Python needs access to the return value from a malloc() call.
>
> >>Really ? Why ? You say your C++ code needs to access the pointer(s).
> >>Python has no notion of "pointer", but it will happily pass around
> >>atever data you expose from C++.
>
> Sorry about that Stefan, my post should have been clearer.
>
> I know Python doesn't know about pointers.
> I should have said "Python needs access to the memory pointed to by
> the memory allocated with malloc()".
>
>
> >>f you expose the above class together with the constructor and thei
> >>'call_ioctl()' member function I think you have all you need.
>
> In your something class, the data type returned from allocate_memory()
> needs to be something that Python understands. Since that allocation
> function (member) will be allocating 100s of MB of memory, how will
> this memory map to a Python data type?

Does it have to be a Python (native) data type ? Could you explain your
use-case a little more ?

>
> Is a bytearray better to use than a list (as far as performance is
> concerned)? Is a list better to use than a string (as far as
> performance is concerned). Are there other data types that should be
> considered?

It all depends on what you intend to do with the memory.

>
> The user will need to access that data as bytes, words, longs, and
> possibly sequences.
>
> I've tried using boost's extract, to convert the char * returned from
> malloc() into a Python string,
> and a Python list, but these result in compile errors.

That's because the extract<>() logic is meant to be used for the
inverse: to get access to C/C++ objects embedded into a Python object.
Once you reflect your C++ type "something" to Python, boost.python will
implicitly convert between the Python (wrapper) type and the C++
"something" type for all function calls.
However, sometimes you may still have a Python object, knowing that it
actually contains a "something". extract<> is meant to give access to
that (either by-value or by-reference, depending on your usage).

If you really need to expose the memory as a buffer to Python, you may
want to use one of the newer C APIs such as
|PyMemoryView_FromMemory
(https://docs.python.org/3/c-api/memoryview.html). Support for that
isn't built into boost.python yet, so you'll have to add some glue code
(e.g.
http://stackoverflow.com/questions/23064407/expose-c-buffer-as-python-3-bytes).
This may actually be worth including into the library. We just haven't
had anyone asking for such a feature - yet.
|
(I have used similar approaches in the past, where memory from a C++
library I wrote is bound to a NumPy array, so the data can be accessed
copy-free from other Python modules via the NumPy interface.)

Regards,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Passing memory allocated in C++ to Python

[Stefan Seefeld]

On 12.01.2016 13:54, Tony Cappellini wrote:
>
> > In your something class, the data type returned from allocate_memory()
> > needs to be something that Python understands. Since that allocation
> > function (member) will be allocating 100s of MB of memory, how will
> > this memory map to a Python data type?
>
> >>Does it have to be a Python (native) data type ? Could you explain your
> >>use-case a little more ?
>
> It needs to be a data type that can be allocated in C++ but accessible
> in Python

"accessible" is too vague. The question is what interface you need,
whether an object-oriented one with methods to access and modify the
internal state, or one giving you unstructured access to the raw data.

>
> >>Could you explain your use-case a little more ?
> I have C++ code which is interfacing to a driver, from Python.
> The user invokes a python function which calls my C++ code (via
> Boost). The C++ code makes a C++ structure, allocates memory for the
> ioctl call,
> puts a pointer to the allocated memory into the C++ structure (as well
> as filling in other structure members), calls the ioctl and returns
> the success/failure
> results to Python. The user needs a way to get access to the allocated
> memory, which was filled in by the ioctl call.

Can you share your code, or at least a stripped-down version ? I think
at this point it would make more sense to go over some specifics.
Your description above doesn't sound very object-oriented. You are
calling a function that returns the success of the operation. What you
actually want is return an object that holds the state (including the
memory you are talking about), which you can then manipulate in
subsequent calls.

Even some pseudo-code would do, to discuss the general idea.

> I should have mentioned that I am using Python 2.7 (as part of a group
> project- others are using Python 2.7 as well).
>
> Python 3.x is out of the question at the moment, but the memory view
> looks like an interesting idea.

Fine, I just mentioned it to illustrate the idea. There are other APIs
to achieve the same.

Regards,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Passing memory allocated in C++ to Python

[Stefan Seefeld]

Hi Tony,

On 11.01.2016 17:56, Tony Cappellini wrote:
>
>
> I've already got a project built for Linux, using Boost-python. My
> Python code can import the C++ extension and access the members that
> are exposed.
>
> My C++ code needs to call fill in C++ structures in order to call
> ioctl() functions, while passing the addresses of the structures to
> the ioctl functions. 
>
> I also need to allocate large (10's of MB - 100s of MB) buffers which
> must be aligned to specific boundaries. A pointer to these buffers are
> part of the above-mentioned C++ structs.
> (I already have the C++ functions which handle the alignment and
> memory allocation)
>
> The problems I'm facing are:
>  1. How to initiate the memory allocation from Python, so that the
> user has access to the
>  data after the ioctl() completes. This would eliminate the
> need from copying the data from
> C++ to Python, after each ioctl() call.
>  2. Using boost-python, which type of Python data structure is
> best suited to be shared across
>  the C++/Python boundary? Keep in mind that the allocation
> needs to happen in C++ so that 
>  memory alignment can be maintained, but initiating the
> allocation/alignment will be done from 
>  Python.

What you are describing all sounds quite feasible.

>
> Essentially- Python needs access to the return value from a malloc() call.

Really ? Why ? You say your C++ code needs to access the pointer(s).
Python has no notion of "pointer", but it will happily pass around
whatever data you expose from C++.

So let's say you have a C++ class (or struct if you prefer) that
encapsulates the data and methods, such as:

class something
{
  public:
something() : buffer_(allocate_memory()) {}
void call_ioctl() { /*...*/}
  private:
char *buffer_;
};

if you expose the above class together with the constructor and the
'call_ioctl()' member function I think you have all you need.

If not, please elaborate.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] pybind11 -- alternative to Boost.Python

[Stefan Seefeld]

On 19.10.2015 06:24, Wenzel Jakob wrote:
> I would be open to it but have my doubts about the feasibility of a
> merge. Consider the difference in code size alone: Boost.Python
> (without dependencies like MPL etc.) uses 26K lines of code, compared
> to about 2K for pybind11 (3K with all extensions). Apart from that,
> the libraries take very different internal design decisions, which
> would likely break existing software that ventures beyond the basic
> .def() syntax.

Hi Wenzel,

Indeed, I would be very interested in a detailed comparison. Modernizing
Boost.Python by using C++11 features (for example) and stripping out
obsolete compiler support is one way to move forward. That in itself
will help a lot, and may even allow Boost.Python to strip off
dependencies to other Boost libraries.

I'd be curious to learn about those design decisions that you are
alluding to that lead to incompatibilities. Such a document may
ultimately also be important for potential users when they consider the
alternatives.

Regards,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] register c++ std::pairstring, string and std::pairstring*, string*

[Stefan Seefeld]

On 28/08/15 09:26 AM, MM wrote:
 This is in too separate modules.
 The converter is registered in module1, and the class_range_t in
 module 2.
 I import 1 then 2, then it happens

 Also the intents are different. THe pairstring,string is to be
 considered as a (str1,str2) tuple of 2 values.
 The pairstring*, string* is the [begin, end[ iterators into an array
 with value_type string


Oups, sorry, I hadn't noticed that they had different types. Can you
please post a minimal bug self-contained test case ? I'd like to debug
this a bit to better understand what is going on. I believe this should
work as there is no reason the two types should be confused. (It
obviously depends on your Converter type, which you haven't shown.)

Thanks,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] register c++ std::pairstring, string and std::pairstring*, string*

[Stefan Seefeld]

On 28/08/15 07:49 AM, MM wrote:

 I expose the return type of a C++ function that is a pair of strings
 with the following snippet:

 |to_python_converterstd::pairstd::string,std::string,Converter();|

 Later, I have a unrelated C++ range type:

 |typedef std::pairconst std::string*,const std::string*range_t;|

 which I export as:

 |class_range_t(range).def(__iter__,range(...,...));scope().attr(allitems)=object(ptr(R));|

 where R is of type range_t

 in python, allitems can be iterated over.

 The only issue is I get the following warning:

 |/usr/lib64/python3.4/importlib/_bootstrap.py:321:RuntimeWarning:to-Pythonconverter
 forstd::pairstd::string const*,std::string const*already
 registered;second conversion method ignored.|

 Is there a way to avoid this warning?


Why do you need the explicit converter if you also define a
class_range_t ? Wouldn't everything work just fine without it ?

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] register c++ std::pairstring, string and std::pairstring*, string*

[Stefan Seefeld]

On 28/08/15 10:15 AM, MM wrote:


 On 28 August 2015 at 15:01, Stefan Seefeld ste...@seefeld.name
 mailto:ste...@seefeld.name wrote:

 On 28/08/15 09:26 AM, MM wrote:
  This is in too separate modules.
  The converter is registered in module1, and the class_range_t in
  module 2.
  I import 1 then 2, then it happens
 
  Also the intents are different. THe pairstring,string is to be
  considered as a (str1,str2) tuple of 2 values.
  The pairstring*, string* is the [begin, end[ iterators into an
 array
  with value_type string


 Oups, sorry, I hadn't noticed that they had different types. Can you
 please post a minimal bug self-contained test case ? I'd like to debug
 this a bit to better understand what is going on. I believe this
 should
 work as there is no reason the two types should be confused. (It
 obviously depends on your Converter type, which you haven't shown.)

 Thanks,
 Stefan
  

 Well, there's something about the fact that pointer types somehow
 change to the types pointed to I don't understand it well

Yes, sure: by default, if you pass a pointer-to-A to Python, it will
actually pass the A, unless you use the 'ptr()' wrapper. But that
doesn't mean a container-to-A and container-to-pointer-to-A should be
confused...

I'll look at your sample code, thank.
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] register c++ std::pairstring, string and std::pairstring*, string*

[Stefan Seefeld]

On 28/08/15 10:15 AM, MM wrote:

 Load 1 then 2 it should trigger the warning. 
 Apologies for missing the includes.

I had to modify your code a bit as it triggers errors when compiled
as-is. And with those modifications it didn't see any warning.
Could you please post code that I can compile without any modifications ?

Thanks,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Extracting base object reference of arbitrary Python object

[Stefan Seefeld]

Hi Jeremy,

I think you have a fundamental misunderstanding of the Boost.Python API,
so I suggest you step back a little to first get a better sense of how
the mapping between the two languages works:

On 18/08/15 04:38 AM, Jeremy Murphy wrote:

 struct Point : public boost::python::object {}
 struct LinearRing : public boost::python::object {}

There is really no point in deriving your own types from
boost::python::object. Instead, you should take your own (existing !)
types and embedd them into Python objects using a mechanism described in
detail in the Boost.Python tutorial:
http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html



 which I can then adapt by specializing the required traits class
 templates. My algorithm in C++ looks something like:

 void native_algorithm(boost::geometry::model::point const x) {...}

 void python_algorithm(boost::python::object const x)
 {
 native_algorithm(static_castPoint const(x));
 }

(I'm not entirely understand what you are trying here. Notably, what's
the relationship between the type 'Point' (which you have defined above)
and boost::geometry::model::python ?)

I suggest you start by carefully reading the tutorial referenced above,
to see how C++ objects can be embedded into (and extracted from) Python
objects.
That may not yet answer all your questions, but I'm convinced that once
you understand the techniques described there, you will ask
fundamentally different questions, which I'll gladly try to answer. :-)

Regards,
Stefan



-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] virtual functions with default implementation

[Stefan Seefeld]

On 17/08/15 02:12 PM, Nikolay Mladenov wrote:
 If you export an abstract class, create an object from python and call
 its virtual from C++ it should not work without the default
 implementation.

The tutorial explains that well:

for the case of an abstract base, use

  def(func, bpl::pure_virtual(Base::func))

which will provide an implementation that does nothing but raise a
Python exception to tell the caller that the method isn't implemented.

For the case with default implementation, the tutorial gives this wrapper:

  struct BaseWrap : Base, bpl::wrapperBase
  {
virtual std::string func() const
{
  if (bpl::override f = this-get_override(func))
return f();
  else
return Base::func();
}
std::string default_func() const { return this-Base::func();}
  };

and it seems to me much more natural to implement the default case
directly in the else branch above, rather than add it to the def() call.

Stefan



 On Mon, Aug 17, 2015 at 8:03 AM, Stefan Seefeld ste...@seefeld.name
 mailto:ste...@seefeld.name wrote:

 Hi,

 I'm reviewing the Boost.Python tutorial, and I'm stumbling over the
 section on Virtual Functions with Default implementations
 
 (http://boostorg.github.io/python/doc/html/tutorial/tutorial/exposing.html#tutorial.exposing.virtual_functions_with_default_i).
 It mentions the need to provide a separate default implementation
 function as third argument to def(), without explaining why that is
 needed.
 In fact, I'm trying various alternatives (abstract, non-abstract),
 and I
 can't find a need for it. All my tests work fine without it.

 Does anyone know why this is needed, and could perhaps even provide a
 little test case ?

 Thanks,
 Stefan

 --

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

 ___
 Cplusplus-sig mailing list
 Cplusplus-sig@python.org mailto:Cplusplus-sig@python.org
 https://mail.python.org/mailman/listinfo/cplusplus-sig




 ___
 Cplusplus-sig mailing list
 Cplusplus-sig@python.org
 https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost.Python C++ object reference in Python: unexpected behaviour.

[Stefan Seefeld]

On 02/06/15 01:34 AM, Christoff Kok wrote:
 Hi,

 This looks like a bug in Boost.Python to me.

 Could anyone confirm this? I provided a minimal, full working example.

 I would like to make sure it is a bug before reporting it as one.

The 'is' operator compares the identities of the two Python objects,
which differ. However, both are referencing the same C++ object.
As a test, add

bool identical(Factory f1, Factory f2) { return f1 == f2;}

to your C++ and expose that, then use that function to compare the
factory references, instead of 'is'.
Yes, it would be nice if the same Python (wrapper) object would be
returned. I'm not sure how to do that, though. I'll think about it some
more...

HTH,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

[C++-sig] C++ copy construction and Python object copies

[Stefan Seefeld]

Hello,

Python's copy module allows for objects to be copied. The protocol for
this will look up special method __copy__. It seems to me that this
would trivially work for C++ objects providing a copy-constructor.
However, the copy-constructor isn't automatically bound to __copy__.
While I can certainly add that in user-code, I wonder why this isn't
done by Boost.Python itself.
Does anyone know the reasons for this ? Would it seem useful to add that
feature ?

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] subprocess fork() sometimes hangs when called from within boost::python::exec_file

[Stefan Ring]

On Tue, May 5, 2015 at 4:00 PM, Stefan Ring stefan...@gmail.com wrote:
 See also http://caml.inria.fr/mantis/view.php?id=5893. Maybe
 RedHat's bugfix never made it into mainline, or the problem
 reappeared.

Completely unrelated to boost::python, but I guess you could just
block the SIGPROF signal before forking and unblock it afterwards. The
RHEL 5 kernel has apparently been patched with some sort of
workaround, but this has not made it into mainline or the later RHEL
branches.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] subprocess fork() sometimes hangs when called from within boost::python::exec_file

[Stefan Ring]

On Mon, May 4, 2015 at 8:45 AM, Peter Schüller schuelle...@gmail.com wrote:
 Could you suggest a way to get more useful debugging information to
 track down the problem?

I'd try to find out if there is a signal handler for signal 56 (I'm
guessing that's the signal number) and where it's coming from.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] subprocess fork() sometimes hangs when called from within boost::python::exec_file

[Stefan Ring]

On Tue, May 5, 2015 at 3:48 PM, Stefan Ring stefan...@gmail.com wrote:
 On Mon, May 4, 2015 at 8:45 AM, Peter Schüller schuelle...@gmail.com wrote:
 Could you suggest a way to get more useful debugging information to
 track down the problem?

 I'd try to find out if there is a signal handler for signal 56 (I'm
 guessing that's the signal number) and where it's coming from.

Actually, it's SIGPROF (27), as I just noticed.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost.Python As Engine's Scripting Language

[Stefan Seefeld]

On 28/04/15 02:35 AM, Oam wrote:

[...]

 How would I make it so it retrieves the TestPiece class for execution
 without having to manually create an object on the python side. What I
 really want is for the object to exist on the cpp side, but the python
 side is what is manipulating it's behavior.

The approach I typically use for this is the same in Python and C++:
After the script has been run, the main_namespace dictionary will
contain all the objects (including types) that the script added. Thus
it's possible to iterate over all the content and look for types that
are derived classes of MagicEngine.BaseBehavior. Once you have those
you may instantiate objects of those types and operate on them in your
main application's runtime.
In that sense the python script really becomes a configuration file
rather than an executable script.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Compile C++ to python extension

[Stefan Seefeld]

On 23/04/15 04:28 AM, Quentin Blanchon wrote:
 Hi,
 I'm trying to compile C++ class to a python module extension.
 I found a way
 here: 
 http://www.boost.org/doc/libs/1_52_0/libs/python/doc/building.html#configuring-boost-build

 but it doesn't work with versions after boost_1_54, because
 /tools/build/v2 doesn't exist.
 I need help to do this with last update and i need some explaination
 about how to link the  needed libraries.

Unless you are restricted to a particular version of Boost, I recommend
using the latest version. In particular, please always use the version
of the documentation corresponding to your version of the library.

Then report any discrepancies you find. (For issues with the build
system I recommend the Boost mailing list, where many more people hang
around that are able to help with Boost.Build issues.)

Thanks,
Stefan



-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost.Python contains compile fix

[Stefan Seefeld]

On 30/03/15 11:16 AM, Huebl, Axel wrote:
 Hi,


 adding more Python 3 features, the contains method was added (in 1.55.0?)
   http://www.boost.org/doc/libs/1_55_0/libs/python/doc/news.html

 Unfortunately, I found a nasty compile bug when compiling with nvcc that
 I tried to fix in
   https://github.com/boostorg/python/pull/14

 Does anyone know how to test my patch to see if this function is still
 working as expected?

I have looked at your patch, but am not convinced that this is the right
fix. It would be best to really map contains to __contains__ to
preserve the precise semantic of that call.
Do you see the incomplete type error only with nvcc or also with other
compilers (clang, notably) ?

Thanks,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost.Python contains compile fix

[Stefan Seefeld]

On 30/03/15 04:37 PM, Huebl, Axel wrote:
 On 30.03.2015 17:42, Stefan Seefeld wrote:
 On 30/03/15 11:16 AM, Huebl, Axel wrote:
 Hi,


 adding more Python 3 features, the contains method was added (in 1.55.0?)
   http://www.boost.org/doc/libs/1_55_0/libs/python/doc/news.html

 Unfortunately, I found a nasty compile bug when compiling with nvcc that
 I tried to fix in
   https://github.com/boostorg/python/pull/14

 Does anyone know how to test my patch to see if this function is still
 working as expected?
 I have looked at your patch, but am not convinced that this is the right
 fix. It would be best to really map contains to __contains__ to
 preserve the precise semantic of that call.
 Do you see the incomplete type error only with nvcc or also with other
 compilers (clang, notably) ?

 Thanks,
 Stefan

 Hi Stefan,


 I did only triggered the compile error it with nvcc since that is the
 target I want to move Boost.Python to.

 The main problem is actually in accessing the this-attr() method since
 it's return type const_object_attribute is not yet fully typed.

 Maybe it is therefore enough to just move the implementation of
   api::object_operatorsU::contains

 down to a source file, but I did not find an according
   object_core.cpp

 Do you have any hints on that?

Not yet. I was asking about clang because I believe nvcc is based on
clang, and woud thus allow me to attempt to reproduce the problem
without having to install nvcc first.

(I have run into issues such as the above with my own code using clang,
but refactoring the code to make sure all the right pieces are seen in
the right order can open up a huge rat-hole, if there are circular
dependencies...)

 oh that wasn't precise enough: to answer your question,
   I did not try it with clang (yet).

Trying that would be useful, I think.

Thanks,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Memory management in Boost.Python

[Stefan Seefeld]

On 10/03/15 11:24 PM, Ernie Lee wrote:
 Hi Stefan,

   I updated my code so it now use 'boost::shared_ptr' class while
 specifying the held-type and i got exactly the same errors (i guess
 boost did recognize class even in different namespace).

   Any other theories of what could be wrong? Could it be that Python
 in some cases tries to manage memory directly, disregarding SP layer?

In that case I suggest you narrow down the failure into a minimal test
case and send that to the list. Otherwise this would be highly
speculative and thus inefficient.

Regards,
Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Memory management in Boost.Python

[Stefan Seefeld]

Ernie,

it appears what you are seeing is the fact that boost.python only
supports boost::shared_ptr, but not std::shared_ptr. (See
https://svn.boost.org/trac/boost/ticket/6545). Is it possible for you to
switch to Boost's shared_ptr, at least for the Python bindings ? Yes, we
need to fix this urgently... :-(

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] passing by non-const reference?

[Stefan Seefeld]

On 18/02/15 05:13 PM, Christopher O'Grady wrote:
 Hi,

 Based on websearches we have done, we believe that boost-python does
 not allow passing arguments by non-const-reference (at least, not
 easily).  Can someone confirm this is still the case, or point me to
 some documentation that discusses it?  We think this prevents us from
 return multiple arguments from a method call.

 Looking through the mailing list archives, we believe this is
 impossible.  If someone knows differently can you let us know?

If I understand your question, you aren't so much asking about const vs.
non-const arguments, but rather passing by value vs. passing by reference.
Whenever I want to return multiple values, I write a wrapper function
that packs the return values into a tuple, making the interface more
pythonic. For example:


void func(int input, int out1, int out2);

tuple pyfunc(int input)
{
  int out1, out2;
  func(input, out1, out2);
  return make_tuple(out1, out2);
}

...
and then wrap pyfunc instead of func.

Does this address the problem you are trying to solve ?


Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost.Python: Review of Patches

[Stefan Seefeld]

Axel,

I'm trying to look into the open patches to see whether I can help
shrink the list of open issues. The issues / patches I have seen from
you all look minor / sensible, so I hope I can merge them soon. Still
trying to get back up-to-speed with the boost build and test processes etc.

I'm subscribed to both the c++-sig as well as the boost mailing lists. I
think the former might be slightly better to discuss boost.python
issues, if only for the higher SNR.

FWIW,
Stefan

On 02/02/15 01:43 PM, Huebl, Axel wrote:
 Hm, the language binding is dead and 404
   http://sourceforge.net/p/boost/mailman/boost-langbinding/

 Has anyone an idea about my question? :)

 Best,
 Axel
 On 28.01.2015 15:21, Huebl, Axel wrote:
 Oh I just realized
   boost-langbinding

 is the better place to report this.

 Sry for cross-posting, I will migrate my question there.


 Best,
 Axel

 On 28.01.2015 15:01, Huebl, Axel wrote:
 Hi,

 I was directed here from the Boost groups homepage
   http://www.boost.org/community/groups.html#cplussig

 so I hope my question is well placed.

 I was wondering if, how and when patches for Boost.Python (specially bug
 fixes) are merged.

 When I reported two bugs (including patches) beginning of the month
 (that sounds a bit impatient - so if I am just pushing to much just tell
 me) in both trac and on GitHub:
   https://svn.boost.org/trac/boost/ticket/10932
   https://svn.boost.org/trac/boost/ticket/10933

 I noticed that there are other pull requests since at least two boost
 stable releases on GitHub
   https://github.com/boostorg/python/pulls
   (some of them also with a trac issue)

 that have not yet been reviewed/included/commented-on/closed in the code
 base even if they are most of the time straight forward fixes.

 My background:
   I am combined Boost.Python with via cmake with an open source, (mpi)
 parallel, many-GPGPU code [1] compiled with nvcc 6.5 and noted some
 minor compile errors in Boost.Python that can be fixed quite easily.

 (Btw: it works like a charm, thank you so much!)


 Best regards,
 Axel Huebl

 [1] http://picongpu.hzdr.de



 ___
 Cplusplus-sig mailing list
 Cplusplus-sig@python.org
 https://mail.python.org/mailman/listinfo/cplusplus-sig



 ___
 Cplusplus-sig mailing list
 Cplusplus-sig@python.org
 https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Weird function call results

[Stefan Seefeld]

On 18/12/14 06:13 AM, ilias wrote:
 I got an overloaded function:

 void f(int n)
 {
   std::clog  invoked f(int n =   n  )  std::endl;
 }

 void f(double d)
 {
   std::clog  invoked f(double d =   d  )  std::endl;
 }

 If I put declarations in that order:

 void (*f_int)(int) = f;
 void (*f_double)(double) = f;

 BOOST_PYTHON_MODULE(test)
 {
   def(f, f_int);
   def(f, f_double);
 }

 No matter what I pass into the function f, f(double) is invoked every time. 
 Even though I call f(int(1)) I will see invoked f(double d = 1).

 But if I declare the function f in reversed order:

 BOOST_PYTHON_MODULE(test)
 {
   def(f, f_double);
   def(f, f_int);
 }

 I will see invoked f(int n = 5) when I call f(5) and invoked f(double d = 
 3.14) when I call f(3.14) as it has to be. Why does it happen? Why does it 
 depend on declaration order?

It definitely shouldn't. If it does, please submit a bug report
including the test, as well as details as to what compiler and OS you
were observing the error on.

Thanks,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Passing opaque data to C++ callback from Python

[Stefan Seefeld]

On 16/12/14 11:13 PM, Peter LaDow wrote:
 I'm embedding Python (using boost::python) into an application plugin
 that uses callbacks. Essentially, I want to do something like:

 In Python (say test.py):

 def do_something():
   ...

 register_callback(do_something)

 And on the C++ side I register the register_callback() function:

 void register_callback(boost::python::object o)
 {
 // Access some persistent state information
 }

You defined 'do_something' as a callback, and registered it so it could
be called from C++, yes ? Then, in your implementation of
'register_callback', 'o' is actually a reference to your callback
function. Do you want to access the persistent state while registering
the callback, or from within the callback ? Or am I misreading the code
above ?

Stefan

 BOOST_PYTHON_MODULE(foo)
 {
   boost::python::def(register_callback, register_callback);
 }

 void library_entry()
 {
   PyImport_AppendInittab(foo, initfoo);

   PyInitialize();

   // Create some persistent state information

   boost::python::exec_file(test.py, ...);
 }

 The issue here is that I need to create the Python context and store
 things away in an opaque pointer I return to the application. And when
 Python calls back into the C++, I need to recover that opaque value.
 For example:

 Application -- (calls) -- my C++ library -- (runs) -- Python script
 -- (calls) -- my C++ library

 For that last step, I need to recover some opaque data. Further, I
 need that opaque data to be persistent. The calls into my C++ library
 are callbacks from the application. The issue I'm having is trying to
 figure out how to pass that state information to the C++
 register_callback() function. I've tried something like:

 namespace bp = boost::python;

 class state_info_t
 {
 };

 void register_callback(std::shared_ptrstate_info_t state, bp::object o);
 {
   // Access some persistent state information
 }

 // Create some persistent state information
 std::shared_ptrstate_info_t state = std::make_sharedstate_info_t();

 PyImport_AppendInittab(foo, initfoo);

 Py_Initialize();

 std::shared_ptrbp::object main_module =
 std::make_sharedbp::object(bp::handle(bp::borrowed(PyImport_AddModule(__main__;
 bp::object main_namespace = main_module-attr(__dict__);
 std::shared_ptrbp::object foo_module =
 std::make_sharedbp::object(bp::handle(PyImport_ImportModule(foo)));

 main_namespace[foo] = *foo_module;

 bp::scope foo_scope(*foo_module);

 // Both of these fail with _a lot_ of errors, most related to no
 matching function call to 'get_signature'
 bp::def(register_callback,
 [](bp::object o) { register_callback(state, o); },
 bp::arg(func));

 bp::def(register_callback,
 std::bind(register_callback, state, std::placeholders::_1),
 bp::arg(func));

 The other thought I had was to store the persistent data in the
 module's dictionary. But I don't know how to recover it in the
 callback. For example:

 // Create some persistent state information
 std::shared_ptrstate_info_t state = std::make_sharedstate_info_t();

 PyImport_AppendInittab(foo, initfoo);

 Py_Initialize();

 std::shared_ptrbp::object main_module =
 std::make_sharedbp::object(bp::handle(bp::borrowed(PyImport_AddModule(__main__;
 bp::object main_namespace = main_module-attr(__dict__);
 std::shared_ptrbp::object foo_module =
 std::make_sharedbp::object(bp::handle(PyImport_ImportModule(foo)));
 bp::object foo_namespace = main_module-attr(__dict__);

 main_namespace[foo] = *foo_module;
 foo_namespace[state] = bp::handle(state); // Whatever the
 appropriate wrapper is

 Then in C++ side of register_callback:

 void register_callback(bp::object o)
 {
   // How do I extract state from the context?
 }

 I'm not keen on this last one, since it exposes the state information
 to the script.

 I don't want to make the state information global since there may be
 multiple running Python instances. And regardless, with multiple
 Python instances I still need a way to determine which Python instance
 is running to select the appropriate state information.

 Any suggestions?
 ___
 Cplusplus-sig mailing list
 Cplusplus-sig@python.org
 https://mail.python.org/mailman/listinfo/cplusplus-sig


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] sharing code between different python extensions

[Stefan Seefeld]

On 28/10/14 06:46 AM, Wintersberger, Eugen wrote:
 Hi Stefan

 On Fri, 2014-10-24 at 07:12 -0400, Stefan Seefeld wrote:
 
 Alternatively you could try to reduce the
 dependency to only exist at the Python interface level, such that using
 'b' requires 'a' being loaded (for example to enable type converters
 defined in 'a' but used in 'b'), but without any direct ABI dependencies
 between 'a' and 'b'.
 This is interesting as it is much closer to my real problem. Extension
 'a' provides some converters from numpy objects to my own C++ types and
 back. And these guys I would like to use in 'b' (along with some other
 numpy utility functions).
 And why is that approach then not working for you ?

 Stefan

 Well, I think I found a solution. However, I have no idea how to do this
 with distutils. As you suggested I will build a shared library with the
 common code but bound to a particular Python version. It should be
 installed in 

 $PREFIX/lib/pythonX.Y/some more directories

 and header files to 

 $PREFIX/include/pythonX.Y/some more directories

 What I still do not know is how to build the extension module along with
 the shared library with distutils ;). I guess I will put this question
 on the Python list - or maybe someone at this list has an idea how to do
 this. 
 Thanks for all your efforts so far. 

Eugen,

For avoidance of doubt, I don't think I'm able to help you with that. I
have used distutils in the past, but found it pretty limited in its
support of extension modules.
I ended up adding a few custom commands to build pure C++ libraries
(specifically for dependencies shared by multiple extension modules).
That was never particularly elegant or generic, and so I don't think
it's worth reusing this.

An example of this you can find in
https://github.com/stefanseefeld/synopsis/tree/master/Synopsis/dist (in
case you are brave enough :-) ). I haven't touched that code in quite a
while, and there may be much better solutions these days using more
modern substitutes for the distutils package.

Regards,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] sharing code between different python extensions

[Stefan Seefeld]

On 22/10/14 08:08 AM, Wintersberger, Eugen wrote:
 Hi there
   I have a little problem with two Python extensions (C++ with
 boost::python) where share code. An example of what I am trying to do is
 attached to this mail so I will refer to the code in the tarball to
 explain the problem. 

 I have to Python extensions ('a' and 'b') each of them exporting two
 functions. What I want is to use a function exported by 'a' in the code
 of 'b'. Though the package compiles I get an unresolved symbol error
 when trying to load 'b'. 

 The reason is quite clear. 'b' cannot resolve the symbol as it is
 provided by 'a' to which it is not linked. Is it somehow possible with
 distutils to link the two extensions to that 'b' can see the symbols
 provided by 'a'?

Python extension modules may not depend on each other in that way.
(Arguably that is a Good Thing, as it avoids possible ABI compatibility
issues.)
What I suggest you do is either refactor the code such that your
extensions 'a' and 'b' both link to a shared library 'c' which provides
the symbols used by both. Alternatively you could try to reduce the
dependency to only exist at the Python interface level, such that using
'b' requires 'a' being loaded (for example to enable type converters
defined in 'a' but used in 'b'), but without any direct ABI dependencies
between 'a' and 'b'.

 Stefan



-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] boost python class member getter/setter same name different only by constness

[Stefan Seefeld]

On 2014-10-02 16:09, MM wrote:
 Hi

 class C {
 public:
   const std::string name() const;
   std::string name();
 private:
   std::string name_;
 };

 given this class C, how would I expose it to python with the class
 property name?

 class_C(C).
   .add_property(name,   C::name, C::name);

 or do I use 2 mem function pointers to distinguish the 2 names, and
 pass those 2 pointers?

You need to disambiguate the two overloads. The cleanest way to do that
is to introduce two (local) variables of the appropriate
pointer-to-member-function types, then pass those variables to the
'add_property' call.
In addition, I believe boost.python expects a different signature for
the setter (a function taking a value-type argument), so you may have to
provide a wrapper function for that, unless you want to modify the 'C'
class in-place.

HTH,
Stefan



-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] boost python class member getter/setter same name different only by constness

[Stefan Seefeld]

On 2014-10-03 12:56, MM wrote:
 yes i did that.

 class C {
 public:
   const std::string get_name() const;
   void set_name(const std::string);
 private:
   std::string name_;
 };

  

 class_C(C).
   .add_property(name,   C::get_name, C::set_name);


 this fails to compile because of unspecified call policies about the
 string refs.


 The following, on the other hand, compiles.

 class C {
 public:
   const std::string get_name() const;
   void set_name(const std::string);
 
 class_C(C).
   .add_property(name,   C::get_name, C::set_name);


 Which policy do I specify? and how do I set it in add_property?

Good question. The policy you want is likely pass-by-value (In Python
strings are immutable anyhow), however I have no idea how to express
that with the add_property() call.
As a quick hack I suggest adding a wrapper function that returns the
result by-value:

  std::string get_name(C c) { return c.get_name();}

and use that. That's neither elegant nor efficient (if you call it a
lot), but it may unblock you until you find a real fix.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Building Boost with python2.7 libraries on centos 6.5

[Stefan Seefeld]

On 09/09/2014 06:19 PM, Whitmore, Mattie [USA] wrote:
 Dear All,

 I must build boost 1.46.1 from source since yum does not support it. I
 am running into issues with the proper make commands. I have run:


 ./bootstrap.sh -with-libraries=python -with-python=Python2.7
 -with-toolset=gcc

 ./bjam -a --layout=tagged -q


 libs/python/src/numeric.cpp:22: warning:
 ‘boost::python::numeric::unnamed::array_module’ defined but not used


 g++ -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
 -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE
 -DBOOST_PYTHON_STATIC_LIB -DNDEBUG -I. -I/usr/include/python2.6 -c
 -o
 bin.v2/libs/python/build/gcc-4.4.7/release/link-static/threading-multi/numeric.o
 libs/python/src/numeric.cpp


 ...failed gcc.compile.c++
 bin.v2/libs/python/build/gcc-4.4.7/release/link-static/threading-multi/numeric.o...

 ...failed updating 1 target...


 Does anyone have suggestions on building boost with python libraries?
 Is this because I am not building all of the libraries at once?


The above doesn't contain any actual error, only a warning, so it's hard
to tell what went wrong. Can you sent the full output, please ?

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Exposing a generic template system in Boost.Python

[Stefan Seefeld]

Francesco,

I have done something like what you are suggesting. It essentially boils
down to defining a function template like

template typename T
void define_vector(char const *name)
{
   class_... vector(name);
  ...
}


and then calling that multiple times:

  define_vectorint(IVector);
  define_vectorlong(LVector);
  ...

Providing a factory function that instantiates one of those based on a
value-type selector as you want can be easily done on the Python side.

I don't think this can be automated any further. In particular, it is
clear that any type you may want to instantiate in Python has to be
compiled explicitly into the extension module. I.e., you need to
explicitly instantiate the templates above, by explicitly calling the
functions for the types you want to see supported at runtime. There is
no JIT compilation for this.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] create a python object from scratch in boost.python?

[Stefan Seefeld]

On 01/21/2014 10:37 AM, Gary Oberbrunner wrote:
 So now it returns a python list of python dicts. All I want now is to
 override __getattr__ on each ppinfo dict so it returns the dict value
 as the attribute value, so in python I can reference
 effect_list[i].name instead of effect_list[i]['name']. Or any
 alternative way to get the same effect. Is that possible? 
There are many ways to do that elegantly in Python. For example:

class Effect:
  def __init__(self, mydict):
self.__dict__.update(mydict)

If you want to combine that with existing classes / APIs, you could also
consider merging the new attributes in via metaclasses.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] create a python object from scratch in boost.python?

[Stefan Seefeld]

On 01/21/2014 05:24 PM, Gary Oberbrunner wrote:

 - Original Message -
 From: Stefan Seefeld ste...@seefeld.name
 Have a look at the attached code; I don't think that counts as
 heavy-weight. In particular, trying to do the same without  embedding
 a
 little script would be just more cumbersome, if it worked at all.
 Whoa, that is cool!  I had no idea boost python could do this.  Thanks, 
 Stefan!

 (It's like python-ception: python calls C++ which calls python...)

Yeah, the boundary between the two languages really becomes blurry,
precisely because the two really share the same runtime, so passing
objects across the boundary becomes so seamless you can almost forget
it's there. The beauty of hybrid programming... :-)

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] const_iterator type

[Stefan Ring]

 I couldn't find any examples using const_iterator in the test directory, or
 elsewhere, so can't find anything to go by. I thought to manually add those
 typedef's the compilers complaining about, to a Python wrapper class derived
 from MyIterator. Is there another class I can inherit from, in boost or the
 STL, to do this for me?

Wy can't you add them to the iterator itself? That's where they belong.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] problem embedding python - very simple example

[Stefan Seefeld]

On 11/06/2012 02:40 PM, Cory Riddell wrote:
 It prints hello\nworld\n then throws an exception executing the line
 that creates the hello.txt file:
   First-chance exception at 0x755ac41f in Test.exe: Microsoft C++
 exception: boost::python::error_already_set at memory location 0x0039fb60..
   Unhandled exception at 0x773915de (ntdll.dll) in Test.exe: Microsoft
 C++ exception: boost::python::error_already_set at memory location
 0x0039fb60..

 In the exec method, the exception is being thrown when result comes back
 as null:
   PyObject* result = PyRun_String(s, Py_file_input, global.ptr(),
 local.ptr());
   if (!result) throw_error_already_set();

I suggest you wrap your C++ code in a try block, then catch the
error_already_set error and inspect the Python exception using
PyErr_Print() or somesuch.

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost.python] Can't import a wrapped template class

[Stefan Seefeld]

On 10/26/2012 07:42 AM, Paul O. Seidon wrote:
 Hi all,

 right now I'm doing my first stepps in wrapping C++ code by ude of Boost.

[...]

Where is the definition of your _Variable template instances ? Your
newly compiled Python module can't find them. The likely cause is that
you forgot to link the module to the library containing the definition(s).

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost.python] Can't import a wrapped template class

[Stefan Seefeld]

On 10/26/2012 01:50 PM, Paul O. Seidon wrote:
 The ctor is decl'ed in varbls.h as

 _Variable();

 and it's def'ed in varbls.cpp like so:

 template typename TYPE
 _VariableTYPE::_Variable()
 : _value( 0)
 {
  //ctor
 }

That doesn't work. When the compiler compiles varbls.cpp, it doesn't
know what types to instantiate the _Variable template for, so you need
to either explicitly instantiate it for all the types you use in your
module, or keep the definitions in the varbls.h header so the compiler
can implicitly instantiate them when compiling the Python module.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost.python] Can't import a wrapped template class

[Stefan Seefeld]

On 10/26/2012 02:16 PM, Paul O. Seidon wrote:
 Stefan Seefeld wrote:

 On 10/26/2012 01:50 PM, Paul O. Seidon wrote:
 The ctor is decl'ed in varbls.h as

 _Variable();

 and it's def'ed in varbls.cpp like so:

 template typename TYPE
 _VariableTYPE::_Variable()
 : _value( 0)
 {
  //ctor
 }
 That doesn't work. When the compiler compiles varbls.cpp, it doesn't
 know what types to instantiate the _Variable template for, so you need
 to either explicitly instantiate it for all the types you use in your
 module, or keep the definitions in the varbls.h header so the compiler
 can implicitly instantiate them when compiling the Python module.

 Stefan

 That didn't make any difference. And it would have surprised me, if it did: 
 varbls.h contains the declaration, varbls.cpp contains the definition, the 
 wrapper is in main.cpp. So if the compiler sees any need to include 
 sometihng, it will and the linker will link the definition.

Sorry, let's back up a little. What are you referring to as the
definition in the above ?

Where is the _Variabledouble::_Variable() constructor defined ? You
didn't show me where it was. You only showed me the (still parametrized)
definition in varbls.cpp. If the compiler sees the parametrized
constructor definition, it doesn't know what types to instantiate it
for, so it does nothing (other than validate the code to some degree).
It's only when it instantiates the template for a particular type that
it generates the missing symbol.
But - according to the small chunks of code you have shown me - it only
attempts that instantiation implicitly in your module's code. But at
that point it doesn't see the constructor definition, so it can't
instantiate that.

Perhaps showing a little more of your code / setup would help.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost.python] Can't import a wrapped template class

[Stefan Seefeld]

On 10/26/2012 02:24 PM, Paul O. Seidon wrote:
 Paul O.  Seidon wrote:

 That doesn't do it either. I can't help but post the compete code here to be 
 sure I'm not misunderstood. The lib consists of varbls.cpp and varbls.h and 
 the wrapper main.cpp.

 varbls.cpp
 ==

 #include varbls.h


 template typename TYPE
 _VariableTYPE::_Variable()
 : _value( 0)
 {
 //ctor
 }

[...]

What symbols does your compiled varbls.o file export ? I bet none. And
it can't. That's the problem I'm trying to explain.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] [boost.python] Can't import a wrapped template class

[Stefan Seefeld]

On 10/26/2012 04:15 PM, Paul O. Seidon wrote:

 Yes, I have to provide a TYPE to the tempate to enable the compiler to 
 generate code. Isn't 

 typedef _Variabledouble  VariableDouble;

 BOOST_PYTHON_MODULE(_varbls)
 {

 class_VariableDouble(VariableDouble)
 .def( init())
 .def( initconst double())
 ;
 }

 doing that?

The compiler can only generate code from templates it can see at the
point where the instantiation happens. Since in the snippet above it
doesn't see the _Variable constructor definition, it can't instantiate
it. And at the point where it can see the constructor, it doesn't know
that it needs to instantiate it for type 'double'.

The entire issue disappears if you move your member function definitions
(including the constructor) from varbls.cpp to varbls.h.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to hangle a NULL pointer?

[Stefan Seefeld]

On 10/02/2012 12:29 PM, Luiz Vitor Martinez Cardoso wrote:

 All the members are initialized to 0 or NULL if it's a pointer.

 The problem is that I'm getting a Segmentation Fault message when I
 try to access the pointers members from Python.

Can you elaborate on what you want to happen in that case ? Python has
no notion of pointers, so the pointers would need to be dereferenced. If
that isn't what you want, you need to add some logic to return something
else if the members are not initialized yet.

Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to hangle a NULL pointer?

[Stefan Seefeld]

I would write little wrapper functions that check the pointer, and if
it's NULL, return None instead of the dereferenced value.

To illustrate:

  object get_age(FaceObject f) { return f.getAge() ?
object(*f.getAge()) : object();}

  ...

  class_FaceObject, boost::noncopyable(...).add_property(age, get_age);

Thus, if the pointer is initialized, the value pointed to will be
returned, and if not, None.

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Question on the development of Boost Python

[Stefan Seefeld]

On 05/13/2012 03:28 PM, Michele De Stefano wrote:
 I would simply like to be re-ensured that Boost Python development is
 going on, because I like this library a lot.

You are not alone ! :-)

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Passing C++ object to script Python‏

[Stefan Seefeld]

On 04/27/2012 08:07 AM, Yoann Chaumy wrote:

 so, what should I do in the main to send an instance Personage to the
 script Python ?

Something like the following (assumes the Python interpreter is already
properly initialized):


void call_script(std::string const script, Personage p)
{
  namespace bpl = boost::python;
  bpl::dict global;
  global[personage] = p; // inject 'p' into script's environment
  bpl::exec_file(script.c_str(), global); // run it
}


HTH,
Stefan


-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost::Python to_python converter

[Stefan Seefeld]

DarkAnt,

the problem is that you don't initialize / import the newly defined
module. The attached version works fine for me.

Stefan

-- 

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

#include boost/python.hpp
#include string

struct Unit
{
   int health;
   std::string name;
   std::string type;
   std::pairint,int coord;
};

namespace bpl = boost::python;

BOOST_PYTHON_MODULE(game)
{
  bpl::class_Unit(Unit)
.def_readwrite(health, Unit::health)
.def_readwrite(name, Unit::name)
.def_readwrite(type, Unit::type)
.def_readwrite(coord, Unit::coord)
;
}

int main(int argc, char** argv)
{
  PyImport_AppendInittab( game, initgame); 
  Py_Initialize();
  bpl::object module = bpl::import(game);
  Unit unit1;
  unit1.health = 100;
  unit1.name = Tank;
  unit1.type = Armor;
  bpl::object foo(unit1);
  std::cout  bpl::extractchar const *(bpl::str(foo))  std::endl;
}
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] function template instantiation

[Stefan Seefeld]

Kyle,


On 03/29/2012 05:14 PM, Kyle Cronan wrote:
 So my question is, why isn't taking the address of some instance of a
 templatized function and passing it to def() enough to require the
 function definition to exist?

It certainly is enough to require, but isn't enough to magically make a
definition to appear. Either you provide the definition in the header,
and let the compiler do that magic of instantiating the template
on-demand, or you defer to a separate compilation unit, but then can't
rely on such magic and need to explicitly instantiate.

   Should this be considered a usability
 bug in the library, a problem with my compiler, or maybe neither?

I haven't seen your specific code, but your description sounds like all
is working as expected.

Stefan

-- 

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

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig