Re: [C++-sig] [Boost.Python v3] Planning and Logistics
On 27 Aug 2011 at 12:29, Dave Abrahams wrote: > In that case, if I were you, I would actually start using Git with the > modularized / CMake-ified Boost at http://github.com/boost-lib. If you do go for git, I have found repo embedded per-branch issue tracking (e.g. http://bugseverywhere.org/) to be a god send for productivity because you can raise issues with your own code without bothering the mainline issue tracker about branch specific (and indeed often personal) issues. It has made as much difference to my productivity as adopting git did because I no longer need to keep (and often misplace) post it notes reminding me of things to do. I even coded up a GUI for it for the TortoiseXXX family of revision tracking GUIs which you can find at http://www.nedprod.com/programs/Win32/BEurtle/. This lets you mark off BE issue fixes with GIT/whatever commits. HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Boost.Python v3] Features and Scope
On 08/27/2011 02:08 PM, Stefan Seefeld wrote: On 08/27/2011 04:40 PM, Dave Abrahams wrote: Hmm. I'm guessing the global type registry would still be the default, and per-module registries would override these when available? It sounds like Stefan has a clear use case in mind, and I'd be curious to know what it is. Me too. I believe what we were discussing at the time was a situation where an extension module would not only define converters for its own types, but also common types that may are required by the API. This could in particular include common types from libstdc++. If multiple extension modules do this, than a Python program that happens to use them in the same application may end up with undefined behavior (does this constitute an ODR violation under the hood ?) To make this work, the common type converters need to be factored out and shared. This in itself is impractical (since the original authors may not be aware of this need). Furthermore, a converter may require module-specific behavior, i.e. converting a std::string in the context of one module may be different from the desired conversion in another. Binding converters to particular modules (and requiring to explicitly import / exporting converters) seems like a solution to the above. That's definitely a problem that needs to be addressed. I've encountered it too. I hope to provide more libstd++ conversions in Boost.Python itself, which should alleviate the need for this a bit, but it does need a proper solution. To solve it, I think you'd want anything registered by a specific module to appear both in that module's registry and the global registry, with the module's registry taking precedence. Are there any cases where you'd want something only to appear in the module-specific registry? Jim ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Boost.Python v3] Features and Scope
on Sat Aug 27 2011, Stefan Seefeld wrote: > On 08/27/2011 04:40 PM, Dave Abrahams wrote: >>> Hmm. I'm guessing the global type registry would still be the >>> default, and per-module registries would override these when >>> available? It sounds like Stefan has a clear use case in mind, and >>> I'd be curious to know what it is. >> Me too. > > I believe what we were discussing at the time was a situation where an > extension module would not only define converters for its own types, but > also common types that may are required by the API. That's currently supported by the global registry. > This could in particular include common types from libstdc++. > > If multiple extension modules do this, than a Python program that > happens to use them in the same application may end up with undefined > behavior (does this constitute an ODR violation under the hood ?) Essentially, yes. > To make this work, the common type converters need to be factored out > and shared. This in itself is impractical (since the original authors > may not be aware of this need). Furthermore, a converter may require > module-specific behavior, i.e. converting a std::string in the context > of one module may be different from the desired conversion in another. > > Binding converters to particular modules (and requiring to explicitly > import / exporting converters) seems like a solution to the above. It might be, but your description of what you're actually proposing is pretty vague, still, so it's hard to tell. -- Dave Abrahams BoostPro Computing http://www.boostpro.com ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Boost.Python v3] Features and Scope
On 08/28/2011 02:39 PM, Dave Abrahams wrote: > on Sat Aug 27 2011, Stefan Seefeld wrote: > > >> Binding converters to particular modules (and requiring to explicitly >> import / exporting converters) seems like a solution to the above. > It might be, but your description of what you're actually proposing is > pretty vague, still, so it's hard to tell. I haven't fully thought this through myself yet. In terms of UI I imagine this to work like this: import ext_mod would still keep the converters private to ext_mod by default, so only functions and methods from ext_mod itself would have access to it. To make those converters accessible globally would require an extra step, for example: from ext_mod import __converters__ Thus each python module can decide itself whether or not it wants to access them. Implementation-wise this would imply that a single global registry would be replaced by a linked list of per-module registries. The obvious disadvantage is that converter lookup will be relatively slow. There could still be ways to keep the current behavior, both for backward compatibility but also as an optimization, if the author knows that there is no danger of symbol collision. Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] sending a c++ class to a python function
I'm getting an error when I try to pass down my object that results in
a seg fault. I've registered my class I'm sending down, but when I
actually send it, my program exits at this line in the library right
after I call the importFile() function...
return call(get_managed_object(self, tag),
BOOST_PP_ENUM_PARAMS_Z(1, N, a));
// here's the class I'm trying to send down
class Scene
{
public:
MeshP mesh(int key);
voidclearScene();
CameraP createCamera(QString name);
MeshP createMesh(QString name);
voidsetMesh(int meshKey, MeshP mesh) {
_meshes[meshKey] = mesh; }
QHashIterator meshes() { return
QHashIterator(_meshes); }
QHashIterator cameras() { return
QHashIterator(_cameras); }
CameraP fetchCamera(QString name);
QList importExtensions();
voidimportFile(QString fileName);
voidevalPythonFile(QString fileName);
Scene();
protected:
intuniqueCameraKey();
intuniqueMeshKey();
QStringuniqueName(QString prefix);
private:
QHash _meshes;
QHash _cameras;
//QHash _lights;
QSet _names;
//PythonQtObjectPtr _context;
object _pyMainModule;
object _pyMainNamespace;
public slots:
void pythonStdOut(const QString &s)
{ std::cout << s.toStdString() << std::flush; }
void pythonStdErr(const QString &s)
{ std::cout << s.toStdString() << std::flush; }
};
// first I create the mapping, which I'm not sure is correct, trying
to follow:
http://misspent.wordpress.com/2009/09/27/how-to-write-boost-python-converters/
struct SceneToPython
{
static PyObject* convert(Scene const& scene)
{
return boost::python::incref(boost::python::object(scene).ptr());
}
};
// then I register it
boost::python::to_python_converter();
// then I send it down from inside my Scene object
try {
object processFileFunc =
_pyMainModule.attr("MeshImporter").attr("processFile");
processFileFunc(this, fileName); // seems to error here
} catch (boost::python::error_already_set const &) {
QString perror = parse_python_exception();
std::cerr << "Error in Python: " << perror.toStdString() << std::endl;
}
I'm not really sure what actually is wrong besides something being
setup incorrectly. Do I need to make a python-to-C++ converter as
well even if I'm not sending it back to C++? Or is my convert()
function just improperly implemented? I wasn't sure how much I need
to actually get it to map correctly. Thanks.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
