The type_traits internal details used here are being moved to make it clear they are details and subject to change. Old code will continue to work, but will warn about use of a deprecated header.
Uses of visual studio were getting a 'unresolved external symbol _mainCRTStartup' because there was no main() being linked into the test_embed.exe. I'm not a bjam expert, but I think that is because the embedding target is an executable (instead of an obj/lib?). I also have no idea if this was a problem on unix or if this fix will affect that platform.
* Use `doc/src/*.css` instead of `doc/html/*.css`.
* Remove wiki and people directories.
* Some documentation fixes.
* Left out `minimal.css` changes and boostbook changes because of clashes.
[SVN r63347]
Mostly to use the images and css files under doc/src instead of
doc/html, usually be deleting the settings in order to use the defaults.
Also add 'boost.root' to some builds in order to fix links which rely on
it.
[SVN r63146]
Remark:
operator!() for boost::python::object invokes PyObject_IsTrue()
and is therefore not equivalent to "is None".
In this particular case !global or !local returns true for an
empty dict.
(Changes to libs/python/test/exec.cpp just helped in debugging.)
[SVN r55639]
Tweaked some existing Jamfiles so that PDF build finds all the necessary image files etc.
Tweaked fo.xsl to provide more options by default, and improve formatting.
[SVN r51104]
Merged revisions 48987,49230-49231 via svnmerge from
https://svn.boost.org/svn/boost/trunk
........
r48987 | danieljames | 2008-09-28 13:21:39 +0100 (Sun, 28 Sep 2008) | 1 line
Clean up some link errors.
........
r49230 | danieljames | 2008-10-09 23:13:48 +0100 (Thu, 09 Oct 2008) | 1 line
position_iterator is meant to be a forward iterator, so avoid using operator+ with it.
........
r49231 | danieljames | 2008-10-09 23:14:14 +0100 (Thu, 09 Oct 2008) | 4 lines
Work around the problems with window newlines in position_iterator. (I'm
about to fix them, but this will get quickbook working immediately).
Fixes#2155
........
[SVN r49242]
these changes follow. r44807 is a merge from another branch; many of
those changes probably don't apply.
------------------------------------------------------------------------
r43423 | danieljames | 2008-02-27 14:22:01 -0500 (Wed, 27 Feb 2008) | 1 line
Fix incorrect links to copyright of the form 'http:#www.boost.org
------------------------------------------------------------------------
r43546 | rwgk | 2008-03-08 23:30:13 -0500 (Sat, 08 Mar 2008) | 1 line
map std::invalid_argument -> Python ValueError
------------------------------------------------------------------------
r43799 | grafik | 2008-03-22 18:53:35 -0400 (Sat, 22 Mar 2008) | 1 line
Remove svn exec property from files that should not be executable to fix permission problems in archives.
------------------------------------------------------------------------
r43845 | dave | 2008-03-24 14:27:22 -0400 (Mon, 24 Mar 2008) | 1 line
Work around vc9 bugs
------------------------------------------------------------------------
r43901 | bemandawes | 2008-03-27 22:11:13 -0400 (Thu, 27 Mar 2008) | 1 line
Remove per email from Dave
------------------------------------------------------------------------
r44041 | rwgk | 2008-04-04 14:57:27 -0400 (Fri, 04 Apr 2008) | 1 line
bogus VC8 warning C4180 disabled
------------------------------------------------------------------------
r44449 | djowel | 2008-04-15 23:07:06 -0400 (Tue, 15 Apr 2008) | 1 line
Andreas patch
------------------------------------------------------------------------
r44450 | djowel | 2008-04-15 23:07:11 -0400 (Tue, 15 Apr 2008) | 1 line
Andreas indexing suite patch
------------------------------------------------------------------------
r44807 | danieljames | 2008-04-27 03:39:49 -0400 (Sun, 27 Apr 2008) | 78 lines
Merge in documentation fixes. Apart from the change to optional's documenation
Jamfile, which I included by mistake.
Fixes#1659, #1661, #1684, #1685, 1687, #1690, #1801
I wrote about this at:
http://lists.boost.org/Archives/boost/2008/04/136405.php
Merged revisions 44585-44806 via svnmerge from
https://svn.boost.org/svn/boost/branches/doc
........
r44585 | danieljames | 2008-04-19 16:25:27 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix broken link to vacpp in bjam docs. Refs #1512
........
r44586 | danieljames | 2008-04-19 16:27:36 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix broken link to bcpp in bjam docs. Refs #1513
........
r44587 | danieljames | 2008-04-19 16:33:58 +0100 (Sat, 19 Apr 2008) | 2 lines
DateTime documentation - Fix a link to the serialization library. Refs #1659
........
r44588 | danieljames | 2008-04-19 16:35:36 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix some links in interprocess & intrusive. Refs #1661
........
r44589 | danieljames | 2008-04-19 16:37:39 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix some links in the python docs. Refs #1684.
........
r44590 | danieljames | 2008-04-19 16:38:29 +0100 (Sat, 19 Apr 2008) | 2 lines
Work around a quickbook bug which is affecting the python docs. Refs #1684.
........
r44591 | danieljames | 2008-04-19 16:39:34 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix a broken link in the numeric conversion docs. Refs #1685
........
r44592 | danieljames | 2008-04-19 16:40:45 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix some links in the optional docs. Refs #1687
........
r44593 | danieljames | 2008-04-19 16:42:09 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix link to the hash documentation from bimap. Refs #1690
........
r44599 | danieljames | 2008-04-19 18:07:33 +0100 (Sat, 19 Apr 2008) | 2 lines
Fix a typo in the format library. Refs #1801
........
r44600 | danieljames | 2008-04-19 19:20:59 +0100 (Sat, 19 Apr 2008) | 1 line
Initialise svnmerge.
........
r44641 | danieljames | 2008-04-20 18:59:47 +0100 (Sun, 20 Apr 2008) | 2 lines
Fix the lincense url in shared container iterator documentation.
........
r44642 | danieljames | 2008-04-20 19:00:00 +0100 (Sun, 20 Apr 2008) | 2 lines
Fix image link in the mpi documentation.
........
r44643 | danieljames | 2008-04-20 19:00:11 +0100 (Sun, 20 Apr 2008) | 2 lines
Fix a typo in the spirit docs.
........
r44644 | danieljames | 2008-04-20 19:00:23 +0100 (Sun, 20 Apr 2008) | 2 lines
Escape the slash so that quickbook doesn't think it the start of an italic section, and mess up the link. Refs #1844
........
r44647 | danieljames | 2008-04-20 19:39:47 +0100 (Sun, 20 Apr 2008) | 2 lines
Fix another typo in spirit docs.
........
------------------------------------------------------------------------
r45283 | danieljames | 2008-05-11 09:49:20 -0400 (Sun, 11 May 2008) | 1 line
Quote href values - our tools don't support unquoted values.
------------------------------------------------------------------------
r45359 | rwgk | 2008-05-14 15:38:08 -0400 (Wed, 14 May 2008) | 1 line
braces added to resolve g++ 4.3.0 warning
------------------------------------------------------------------------
r45918 | rwgk | 2008-05-29 15:48:55 -0400 (Thu, 29 May 2008) | 66 lines
See Python C++-SIG thread: "object.attr(object& attrname) proposal"
Started 2008-05-25 by hohehohe2@gmail.com.
Excerpts:
If char const* is passed to objecjt.attr(), it uses
PyObject_GetAttrStrng() or PyObject_SetAttrStrng(). If object is
passed to objecjt.attr(), it takes the object as a Python string
object and uses PyObject_GetAttr() or PyObject_SetAttr().
If attr() behaves like this, it can be useful when there are lots
of objects which you know have the same attribute name. You can save
time by first making a boost::python::object and passing it to every
object's attr() inside a loop.
I just made a bit of modification to boost:python locally and did a
quick test, like
test 1:
for(int i = 0; i < n; ++i)
{
omain.attr(attrname) = 444; //attrname is a char const*
}
test 2:
for(int i = 0; i < n; ++i)
{
object o = omain.attr(attrname); //attrname is a char const*
}
test 3:
for(int i = 0; i < n; ++i)
{
omain.attr(oaaaa) = 444; //oaaaa is boost::python::object that represents a string
}
test 4:
for(int i = 0; i < n; ++i)
{
object o = omain.attr(oaaaa); //oaaaa is boost::python::object that represents a string
}
and it reasonably reflected the difference between PyObject_*Attr() and PyObject_*AttrString.
test 1 :2783ms
test 2 :2357ms
test 3 :1882ms
test 4 :1267ms
test5: PyObject_SetAttrString(po_main, "aaaa", po_num444);
test6: Py_DECREF(PyObject_GetAttrString(po_main, "aaaa"));
test7: PyObject_SetAttr(po_main, po_aaaa, po_num444);
test8: Py_DECREF(PyObject_GetAttr(po_main, po_aaaa));
(po_ prefixed variables are PyObject*),
all inside each for loop, and the results were
test 5 :2410ms
test 6 :2277ms
test 7 :1629ms
test 8 :1094ms
It's boost 1.35.0, Python 2.5 on linux(gcc4.1.2).
I also did the same test on windows(vs8) and the tendency was not
so different.
------------------------------------------------------------------------
r45920 | rwgk | 2008-05-29 16:04:19 -0400 (Thu, 29 May 2008) | 1 line
Projects using Boost.Python: PolyBoRi (text provided by Michael Brickenstein)
------------------------------------------------------------------------
r46115 | schoepflin | 2008-06-04 11:11:05 -0400 (Wed, 04 Jun 2008) | 1 line
Added missing ostream header file.
------------------------------------------------------------------------
r46445 | dgregor | 2008-06-17 09:54:46 -0400 (Tue, 17 Jun 2008) | 1 line
Add mime-type and eol-style properties as needed
------------------------------------------------------------------------
r46721 | dave | 2008-06-26 12:41:34 -0400 (Thu, 26 Jun 2008) | 2 lines
Compatibility with Apache STDCXX library. Don't assume eh.h comes along with the other headers automatically.
------------------------------------------------------------------------
r46808 | bemandawes | 2008-06-28 09:45:21 -0400 (Sat, 28 Jun 2008) | 1 line
With his kind permission, change Jaakko "J<LATIN SMALL LETTER A WITH DIARESIS>rvi" to "Jarvi"
------------------------------------------------------------------------
r46817 | djowel | 2008-06-28 14:24:17 -0400 (Sat, 28 Jun 2008) | 1 line
added note on removing targets
------------------------------------------------------------------------
r46844 | dave | 2008-06-29 08:26:17 -0400 (Sun, 29 Jun 2008) | 2 lines
Make valid HTML
------------------------------------------------------------------------
[SVN r47459]
Started 2008-05-25 by hohehohe2@gmail.com.
Excerpts:
If char const* is passed to objecjt.attr(), it uses
PyObject_GetAttrStrng() or PyObject_SetAttrStrng(). If object is
passed to objecjt.attr(), it takes the object as a Python string
object and uses PyObject_GetAttr() or PyObject_SetAttr().
If attr() behaves like this, it can be useful when there are lots
of objects which you know have the same attribute name. You can save
time by first making a boost::python::object and passing it to every
object's attr() inside a loop.
I just made a bit of modification to boost:python locally and did a
quick test, like
test 1:
for(int i = 0; i < n; ++i)
{
omain.attr(attrname) = 444; //attrname is a char const*
}
test 2:
for(int i = 0; i < n; ++i)
{
object o = omain.attr(attrname); //attrname is a char const*
}
test 3:
for(int i = 0; i < n; ++i)
{
omain.attr(oaaaa) = 444; //oaaaa is boost::python::object that represents a string
}
test 4:
for(int i = 0; i < n; ++i)
{
object o = omain.attr(oaaaa); //oaaaa is boost::python::object that represents a string
}
and it reasonably reflected the difference between PyObject_*Attr() and PyObject_*AttrString.
test 1 :2783ms
test 2 :2357ms
test 3 :1882ms
test 4 :1267ms
test5: PyObject_SetAttrString(po_main, "aaaa", po_num444);
test6: Py_DECREF(PyObject_GetAttrString(po_main, "aaaa"));
test7: PyObject_SetAttr(po_main, po_aaaa, po_num444);
test8: Py_DECREF(PyObject_GetAttr(po_main, po_aaaa));
(po_ prefixed variables are PyObject*),
all inside each for loop, and the results were
test 5 :2410ms
test 6 :2277ms
test 7 :1629ms
test 8 :1094ms
It's boost 1.35.0, Python 2.5 on linux(gcc4.1.2).
I also did the same test on windows(vs8) and the tendency was not
so different.
[SVN r45918]
https://svn.boost.org/svn/boost/trunk
........
r43417 | danieljames | 2008-02-26 22:04:55 +0000 (Tue, 26 Feb 2008) | 2 lines
Fix a link to Boost.Bimap.
........
r43418 | danieljames | 2008-02-26 22:07:25 +0000 (Tue, 26 Feb 2008) | 2 lines
Change another link that's no longer in the repository to link to the website.
........
r43422 | danieljames | 2008-02-27 18:51:14 +0000 (Wed, 27 Feb 2008) | 1 line
Fix broken copyright urls. Fixes#1573.
........
r43423 | danieljames | 2008-02-27 19:22:01 +0000 (Wed, 27 Feb 2008) | 1 line
Fix incorrect links to copyright of the form 'http:#www.boost.org
........
[SVN r43425]
https://svn.boost.org/svn/boost/trunk
........
r43206 | danieljames | 2008-02-10 09:55:03 +0000 (Sun, 10 Feb 2008) | 1 line
Fix some broken links.
........
r43209 | danieljames | 2008-02-10 14:56:22 +0000 (Sun, 10 Feb 2008) | 1 line
Link to people pages on the website, as they've been removed from the download.
........
r43210 | danieljames | 2008-02-10 15:02:17 +0000 (Sun, 10 Feb 2008) | 1 line
Point links to the pages that used to be in 'more' to the site.
........
r43212 | danieljames | 2008-02-10 16:10:16 +0000 (Sun, 10 Feb 2008) | 1 line
Fix links on the home page as well.
........
r43213 | danieljames | 2008-02-10 16:21:22 +0000 (Sun, 10 Feb 2008) | 1 line
Generated documentation which is no longer generated.
........
[SVN r43214]
python.jam:
Support for the specification of "_d" extension suffix.
In compute-default-paths, fixed the check for residence in
a "PCBuild.*" directory so we can build against Windows Python built
in a source distribution.
common.jam:
Fixed generation of the "y" tag to look for <python-debugging>on
rather than the whole debug-python build variant.
Fixed some grammar and spelling.
virtual-target.jam:
Added the ability to forego the prepending of "." to a
generated-target-suffix by specifying the suffix enclosed in <...>
libs/python/build/Jamfile.v2:
#define BOOST_DEBUG_PYTHON when <python-debugging>on
[SVN r37326]
libs/python/test/Jamfile.v2:
* add dynamically-linked embedding test
* fix builtin_converters test so it can work (BBv1 allowed the
duplication of main target names; BBv2 does not)
libs/python/test/import_.cpp: move some more of the Python code within
a handle_exception callback so at least we can better diagnose
failures.
[SVN r37214]
either changing assert(...) or BOOST_ASSERT(...) to BOOST_TEST
(in my code only)
or adding "return boost::report_errors();" where it was clearly
missing (and a pure bug, in anyone's code).
or changing BOOST_TEST to BOOST_CHECK where the integer library
was clearly using Boost.Test and not returning report_errors().
[SVN r37063]
either changing assert(...) or BOOST_ASSERT(...) to BOOST_TEST
(in my code only)
or adding "return boost::report_errors();" where it was clearly
missing (and a pure bug, in anyone's code).
[SVN r37057]
accomodate strange beasts like numarray arrays that return arrays that
can't be used as truth values from their comparison ops.
Fix numpy test for portability with old doctest (again!)
[SVN r35572]
accomodate strange beasts like numarray arrays that return arrays that
can't be used as truth values from their comparison ops.
Fix numpy test for portability with old doctest (again!)
[SVN r35572]
Tests:
* Coerce a result to bool to deal with Python's new Bool type
* Better reporting of mismatches in expected and received results
* Remove bogus nullary y.astype() call
* Fix all uses of trace and diagonal so they don't cause errors
* Use appropriate typecodes
* Use doctest detailed API to run just the relevant tests
* Factor out error handling from macro
API:
* Added get_module_name() function to get current numeric module
* new_(x) now returns an array instead of object
* Fixed the signatures of the factory() family of functions
* Updated docs accordingly.
[SVN r35528]
Tests:
* Coerce a result to bool to deal with Python's new Bool type
* Better reporting of mismatches in expected and received results
* Remove bogus nullary y.astype() call
* Fix all uses of trace and diagonal so they don't cause errors
* Use appropriate typecodes
* Use doctest detailed API to run just the relevant tests
* Factor out error handling from macro
API:
* Added get_module_name() function to get current numeric module
* new_(x) now returns an array instead of object
* Fixed the signatures of the factory() family of functions
* Updated docs accordingly.
[SVN r35528]
from Python's built-in int type. However, the appearance of FILE*
raised questions about using extensions compiled with Visual C++ 8
with a Python compiled with Visual C++ 7.1.
[SVN r32301]
Also moved boost/python/detail/is_xxx.hpp functionality into
boost/detail/is_xxx.hpp to decouple library dependencies between
python and parameter.
[SVN r31290]
this isn't really an elegant solution, perhaps people trying to
debug python (BOOST_DEBUG_PYTHON defined) will really have to
use the debug version of the CRT with the latest .NET
There is also a collision if the user happens to have
#define _CRT_FORCE_MANIFEST which I didn't address
[SVN r30570]
let you get away with typeid(T) when T is an incomplete class
type (that's conforming behavior), but GCC at least will allow
typeid(T&) -- also disallowed by the standard when T is incomplete.
If it turns out that EDGs also barf on typeid(T&), we may have more
work to do.
Some warning suppression for MSVC.
[SVN r29020]
always return a pointer that holds the owning python object *unless*
the python object contains a NULL shared_ptr holder of the right type.
[SVN r28947]
files for some created on the Mac (apparently a HENIOUS crime which is intolerable
to those at Microsoft and which must be considered an error)
Changed - the version of python mentioned specifically from 2.3 to 2.4
[SVN r28471]
methods.
- Applied a patch by Baptiste Lepilleur that allows the user to inject
code inside the class definition.
- Applied another patch by Baptiste Lepilleur that inserts two new command-line
options that helps with writing makefiles.
[SVN r23725]
Clip bounds of slices in a mannar consistant with builtin containers;
Prevent undefined behavior within the STL when given certain kinds of
empty slices.
[SVN r22507]
* Modified Python testing code to use the facilities of testing.jam,
so that it can be processed with process_jam_log
* Updated Python library tests to use a test suite
* Added Python test suite to status/Jamfile
* Added --run-all-tests option to force tests to run even when up-to-date.
Also,
boost-base.jam:
Added some missing rule signatures
RUN_LD_LIBRARY_PATH became LINK_LIBPATH because it was only really
used during linking.
Reformed the movement of path variables up the dependency graph
Removed the defunct Run rule
Set up generalized constants for path manipulation
darwin-tools.jam, gcc-tools.jam:
use LINK_LIBPATH
python.jam:
Reformed the choice of Python executable
testing.jam:
Refactored testing code so it could be used for Python
Now building all environment variable setup code ahead of time
RUN_TEST became TEST_EXE
[SVN r20815]
Fix wstring support so it doesn't break gcc2.95.x, which has no wstring.
Modify CallPolicies protocol so it can safely adjust the argument tuple.
[SVN r20090]
fix a problem which was causing value_holder<T> to be instantiated
on abstract classes. Now we compute the held_type at an outer
level thereby avoiding the inner instantiation.
object_core.hpp -
workarounds for GCC 2.x bugs
suite/indexing/detail/indexing_suite_detail.hpp -
workaround for a CWPro8 bug
[SVN r19635]
"nickm-at-sitius.com" (Nikolay Mladenov) which supplies the
ability to wrap functions that can be called with ommitted
arguments in the middle.
[SVN r19441]
Boost.Python. The major change is that, instead of being
boost::function2<PyObject*,PyObject*,PyObject*>, py_function is now a
runtime-polymorphic wrapper for compile-time polymorphic
behavior (just like function) of our own which carries more
information/behaviors. In particular, you can retrieve an array of
c-strings describing the types in the function signature.
Additionally, the minimum and maximum arity are stored in the
py_function object instead of in the 'function' object which wraps it.
* data_members.hpp -
Adjustments for the new py_function. Workarounds for CodeWarrior
Pro 8.3 bugs in function template argument deduction with
pointers-to-members.
* has_back_reference.hpp, test/back_reference.cpp,
test/select_holder.cpp -
Updated to follow the metafunction protocol
* init.hpp, detail/defaults_gen.hpp -
Make Keywords a more-specific type in function signatures to
prevent string literals that show up as char[N] from binding to
the wrong argument (at least Intel 7.1 for Windows does this).
* make_function.hpp -
Adjustments for the new py_function. Arities are now computed
by caller<>.
* opaque_pointer_converter.hpp, type_id.hpp -
Use BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS facilities;
generate specializations that all compilers can handle.
* raw_function.hpp -
Adjustments for the new py_function.
* caller.hpp -
Added arity and signature type name reporting.
* detail/config.hpp
Enable __declspec(dllexport) for Cygwin, thereby fixing the
recent horrible Cygwin linking problems.
* detail/msvc_typeinfo.hpp -
Always pass boost::type<T>* explicitly, thereby working around
incompatible notions of how to specialize function templates with
default arguments on various compilers.
* object/function.hpp
, object/function_handle.hpp
, object/function_object.hpp
, object/function_object.cpp
Adjustments for the new py_function. Arities are carried by
py_function.
* object/iterator.hpp, object/iterator.cpp
Adjustments for the new py_function; we have to compute a
signature of types to construct it with.
* object/py_function.hpp
Removed dependency on boost::function; see the comment at the
top of this entry for more details.
* object/select_holder.hpp
Clean up to more closely follow MPL idioms.
* test/Jamfile -
Adjust the embedding test for the new Cygwin use of declspec.
Update bases and pointee tests with missing properties.
* test/input_iterator.cpp -
Updates for the new iterator adaptors.
* test/opaque.py -
Add Python encoding comment to suppress PendinDeprecationWarning
with recent Python builds.
* test/str.cpp
Pass a Python long instead of a float to string.expandtabs,
suppressing a PendinDeprecationWarning with recent Python builds.
* libs/utility/counting_iterator_example.cpp
Borland workaround
* libs/utility/indirect_iterator_example.cpp
const-correctness fix.
*
[SVN r19247]
- Added a new function, no_override. When a member function is specified as "no_override", no virtual wrappers are generated for it, improving performance and letting the code more clean.
- There was a bug in which the policy of virtual member functions was being ignored (patch by Roman Sulzhyk).
[SVN r18814]
forward.hpp
pointer_holder.hpp
value_holder.hpp
test/long.[py/cpp]
pointee.hpp, - begin making borland work.
cv_category.hpp,
referent_storage.hpp
instance.hpp
self.hpp - removed flotsam
signature.hpp - use vector instead of list
destroy.hpp - removed needless complication
make_keyword_range_fn.hpp - support for simpler init using vectors
class_converters.hpp - workaround for pro7
inheritance.hpp - simplified; took out pro7 workarounds; factored out
inheritance_query.hpp to reduce recompilation
dependencies
make_ptr_instance.hpp - add missing typename
registry.cpp - add a little invariant checking for metrowerks
class.cpp - stopped relying on class_id typedef
test/data_members.cpp - added a few more tests to make sure things compile at least.
test/destroy_test.cpp - removed cheating has_trivial_destructor tests
test/enum.cpp - added some pro7 workarounds
test/virtual_functions.[py/cpp] - added _some_ tests for callbacks which return by reference.
[SVN r18489]
- Forward-declared classes are ignored with AllFromHeader
- Bug: now it's possible to exclude classes, functions and enums from AllFromHeader
[SVN r18289]
- Now converter operators that return char* or string are automatically named __str__ in Python
- Update documentation with info about Psyco
[SVN r18127]
Various idiomatic MPL cleanups in indirect_traits.hpp
raw_function support
Patches for CWPro7.2
Patches to pass tests under Python 2.3 with the new bool type.
Tests for member operators returning const objects
Fixes for testing Boost.Python under Cygwin
[SVN r17777]
* libs/python/build/Jamfile.v2: Sense the location of python headers. Export
include paths.
* libs/python/example/Jamfile.v2: New file.
* new/targets.jam: Use refined properties for constructed
dependency properties
* new/gcc.jam: Handle 'find-library'. Set soname for dynamic libraries.
* new/builtin.jam: New feature 'find-library'.
[SVN r15966]
* function pointer from a function should work also.
* make_function/make_constructor now return object instead of a raw pointer.
* module::setattr() now accepts anything which can be passed to object's constructor.
* Rework upcast<> to catch more errors at compile-time instead of infinite-looping.
* Rationalize class<>::def() in preparation for docstring support
* Partial docstring support in module::def (untested)
* dependent<> trick moved to detail namespace and separate header
* Added __doc__ attribute to C++ function wrapper objects
* Sunk implementation of function_object into a library source file.
[SVN r14724]
* Proper handling for numeric conversion overflows
* Moved internal converter names out of the way to prepare for user conversions
* Added comments
* Fixed a bug where None could be converted to the NULL target of a member function call, causing a crash.
* Wiped out and restarted todo.txt
* long long support
* Added more regression tests and checks for current limitations
[SVN r14094]
in which the end-user launches a program written in C++ that in turn
invokes the Python interpreter as a library subroutine. Think of adding
scriptability to an existing application.
</li>
</ul></div>
<p>
The key distinction between extending and embedding is the location of the
C++ <codeclass="computeroutput"><spanclass="identifier">main</span><spanclass="special">()</span></code>
function: in the Python interpreter executable, or in some other program,
respectively. Note that even when embedding Python in another program, <ahref="http://www.python.org/doc/current/ext/extending-with-embedding.html"target="_top">extension
modules are often the best way to make C/C++ functionality accessible to
Python code</a>, so the use of extension modules is really at the heart
of both models.
</p>
<p>
Except in rare cases, extension modules are built as dynamically-loaded libraries
with a single entry point, which means you can change them without rebuilding
either the other extension modules or the executable containing <codeclass="computeroutput"><spanclass="identifier">main</span><spanclass="special">()</span></code>.
<aname="building.choosing_a_boost_python_library_"></a><aclass="link"href="choosing_a_boost_python_library_.html"title="Choosing a Boost.Python Library Binary">Choosing a
If—instead of letting Boost.Build construct and link with the right libraries
automatically—you choose to use a pre-built Boost.Python library, you'll
need to think about which one to link with. The Boost.Python binary comes
in both static and dynamic flavors. Take care to choose the right flavor
for your application. <ahref="#ftn.building.choosing_a_boost_python_library_.f0"class="footnote"name="building.choosing_a_boost_python_library_.f0"><supclass="footnote">[3]</sup></a>
A single copy of the library code is used by all extension modules
built with a given toolset. <ahref="#ftn.building.choosing_a_boost_python_library_.the_dynamic_binary.f0"class="footnote"name="building.choosing_a_boost_python_library_.the_dynamic_binary.f0"><supclass="footnote">[4]</sup></a>
</li>
<liclass="listitem">
The library contains a type conversion registry. Because one registry
is shared among all extension modules, instances of a class exposed
to Python in one dynamically-loaded extension module can be passed
As described in the <ahref="http://www.boost.org/build/doc/html/bbv2/overview/configuration.html"target="_top">Boost.Build
Reference Manual</a>, a file called <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> in
your home directory is used to specify the tools and libraries available
to the build system. You may need to create or edit <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> to
tell Boost.Build how to invoke Python, <codeclass="computeroutput"><spanclass="preprocessor">#include</span></code>
If you are using a unix-variant OS and you ran Boost's <codeclass="computeroutput"><spanclass="identifier">configure</span></code>
script, it may have generated a <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code>
for you. <ahref="#ftn.building.configuring_boost_build.f0"class="footnote"name="building.configuring_boost_build.f0"><supclass="footnote">[2]</sup></a> If your <codeclass="computeroutput"><spanclass="identifier">configure</span></code>/<codeclass="computeroutput"><spanclass="identifier">make</span></code> sequence was successful and Boost.Python
binaries were built, your <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code>
file is probably already correct.
</p></td></tr>
</table></div>
<p>
If you have one fairly “standard” python installation for your platform,
you might not need to do anything special to describe it. If you haven't
configured python in <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> (and
you don't specify <codeclass="computeroutput"><spanclass="special">--</span><spanclass="identifier">without</span><spanclass="special">-</span><spanclass="identifier">python</span></code>
on the Boost.Build command line), Boost.Build will automatically execute
which automatically looks for Python in the most likely places. However,
that only happens when using the Boost.Python project file (e.g. when referred
to by another project as in the quickstart method). If instead you are linking
against separately-compiled Boost.Python binaries, you should set up a <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> file
If you have several versions of Python installed, or Python is installed
in an unusual way, you may want to supply any or all of the following optional
parameters to <codeclass="computeroutput"><spanclass="keyword">using</span><spanclass="identifier">python</span></code>.
</p>
<divclass="variablelist">
<pclass="title"><b></b></p>
<dlclass="variablelist">
<dt><spanclass="term">version</span></dt>
<dd><p>
the version of Python to use. Should be in Major.Minor format, for
example, <codeclass="computeroutput"><spanclass="number">2.3</span></code>. Do not
include the subminor version (i.e. <spanclass="bold"><strong>not</strong></span>
<codeclass="computeroutput"><spanclass="number">2.5</span><spanclass="special">.</span><spanclass="number">1</span></code>). If you have multiple Python versions
installed, the version will usually be the only configuration argument
required.
</p></dd>
<dt><spanclass="term">cmd-or-prefix</span></dt>
<dd><p>
preferably, a command that invokes a Python interpreter. Alternatively,
the installation prefix for Python libraries and header files. Only
use the alternative formulation if there is no appropriate Python
If you have both python 2.5 and python 2.4 installed, <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> might contain
The first version configured (2.5) becomes the default. To build
against python 2.4, add <codeclass="computeroutput"><spanclass="identifier">python</span><spanclass="special">=</span><spanclass="number">2.4</span></code>
to the <codeclass="computeroutput"><spanclass="identifier">bjam</span></code> command
line.
</p>
</li>
<liclass="listitem">
If you have python installed in an unusual location, you might supply
the path to the interpreter in the <codeclass="computeroutput"><spanclass="identifier">cmd</span><spanclass="special">-</span><spanclass="keyword">or</span><spanclass="special">-</span><spanclass="identifier">prefix</span></code>
You can set up your user-config.jam so a bjam built under Windows can
build/test both Windows and Cygwin_ python extensions. Just pass <codeclass="computeroutput"><spanclass="special"><</span><spanclass="identifier">target</span><spanclass="special">-</span><spanclass="identifier">os</span><spanclass="special">></span><spanclass="identifier">cygwin</span></code>
in the <codeclass="computeroutput"><spanclass="identifier">condition</span></code> parameter
the existing <codeclass="computeroutput"><spanclass="identifier">user</span><spanclass="special">-</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> in your home directory (if any)
instead. It handles several issues necessary for use with Boost.Python, one
of which is mentioned in the next section.
</p>
<p>
2. Be sure not to <codeclass="computeroutput"><spanclass="preprocessor">#include</span></code>
any system headers before <codeclass="computeroutput"><spanclass="identifier">wrap_python</span><spanclass="special">.</span><spanclass="identifier">hpp</span></code>. This
restriction is actually imposed by Python, or more properly, by Python's
interaction with your operating system. See <ahref="http://docs.python.org/ext/simpleExample.html"target="_top">http://docs.python.org/ext/simpleExample.html</a>
<aname="building.installing_boost_python_on_your_"></a><aclass="link"href="installing_boost_python_on_your_.html"title="Installing Boost.Python on your System">Installing
Boost.Python on your System</a>
</h3></div></div></div>
<p>
Since Boost.Python is a separately-compiled (as opposed to <codeclass="computeroutput"><spanclass="identifier">header</span><spanclass="special">-</span><spanclass="identifier">only</span></code>) library, its user relies on the services
of a Boost.Python library binary.
</p>
<p>
If you need a regular installation of the Boost.Python library binaries on
your system, the Boost <ahref="http://www.boost.org/more/getting_started/"target="_top">Getting
Started Guide</a> will walk you through the steps of creating one. If
building binaries from source, you might want to supply the <codeclass="computeroutput"><spanclass="special">--</span><spanclass="identifier">with</span><spanclass="special">-</span><spanclass="identifier">python</span></code>
argument to <codeclass="computeroutput"><spanclass="identifier">bjam</span></code> (or the
1. Get Boost; see sections 1 and 2 of the Boost <ahref="http://www.boost.org/more/getting_started/"target="_top">Getting
Started Guide</a>.
</p>
<p>
2. Get the <codeclass="computeroutput"><spanclass="identifier">bjam</span></code> build driver.
See section 5 of the Boost <ahref="http://www.boost.org/more/getting_started/"target="_top">Getting
Started Guide</a>.
</p>
<p>
3. cd into the <codeclass="computeroutput"><spanclass="identifier">example</span><spanclass="special">/</span><spanclass="identifier">quickstart</span><spanclass="special">/</span></code> directory of your Boost.Python installation,
the “<codeclass="computeroutput"><spanclass="identifier">stage</span></code>“ argument
from the example invocation from section 5 of the Boost <ahref="http://www.boost.org/more/getting_started/"target="_top">Getting
Started Guide</a> with “<codeclass="computeroutput"><spanclass="identifier">test</span></code>,“
to build all the test targets. Also add the argument “<codeclass="computeroutput"><spanclass="special">--</span><spanclass="identifier">verbose</span><spanclass="special">-</span><spanclass="identifier">test</span></code>” to see the output generated by
the tests when they are run. On Windows, your <codeclass="computeroutput"><spanclass="identifier">bjam</span></code>
For the sake of concision, the rest of this guide will use unix-style
forward slashes in pathnames instead of the backslashes with which Windows
users may be more familiar. The forward slashes should work everywhere
except in <ahref="http://www.boost.org/more/getting_started/windows.html#command-prompt"target="_top">Command
Prompt</a> windows, where you should use backslashes.
</p></td></tr>
</table></div>
<p>
If you followed this procedure successfully, you will have built an extension
module called <codeclass="computeroutput"><spanclass="identifier">extending</span></code>
and tested it by running a Python script called <codeclass="computeroutput"><spanclass="identifier">test_extending</span><spanclass="special">.</span><spanclass="identifier">py</span></code>.
You will also have built and run a simple application called <codeclass="computeroutput"><spanclass="identifier">embedding</span></code> that embeds python.
</p>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h4class="title">
<aname="building.no_install_quickstart.in_case_of_trouble"></a><aclass="link"href="no_install_quickstart.html#building.no_install_quickstart.in_case_of_trouble"title="In Case of Trouble">In
Case of Trouble</a>
</h4></div></div></div>
<p>
If you're seeing lots of compiler and/or linker error messages, it's probably
because Boost.Build is having trouble finding your Python installation.
You might want to pass the <codeclass="computeroutput"><spanclass="special">--</span><spanclass="identifier">debug</span><spanclass="special">-</span><spanclass="identifier">configuration</span></code> option to <codeclass="computeroutput"><spanclass="identifier">bjam</span></code> the first few times you invoke it,
to make sure that Boost.Build is correctly locating all the parts of your
Python installation. If it isn't, consider <aclass="link"href="configuring_boost_build.html"title="Configuring Boost.Build">Configuring
Boost.Build</a> as detailed below.
</p>
<p>
If you're still having trouble, Someone on one of the following mailing
The <ahref="http://www.boost.org/more/mailing_lists.htm#jamboost"target="_top">Boost.Build
mailing list</a> for issues related to Boost.Build
</li>
<liclass="listitem">
The <ahref="http://www.boost.org/more/mailing_lists.htm#cplussig"target="_top">Boost.Python
mailing list</a> for issues specifically related to Boost.Python
</li>
</ul></div>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h4class="title">
<aname="building.no_install_quickstart.in_case_everything_seemed_to_wor"></a><aclass="link"href="no_install_quickstart.html#building.no_install_quickstart.in_case_everything_seemed_to_wor"title="In Case Everything Seemed to Work">In
Case Everything Seemed to Work</a>
</h4></div></div></div>
<p>
Rejoice! If you're new to Boost.Python, at this point it might be a good
idea to ignore build issues for a while and concentrate on learning the
library by going through the <ahref="../tutorial/index.html"target="_top">Tutorial</a>
and perhaps some of the <ahref="../reference/index.html"target="_top">Reference Manual</a>,
trying out what you've learned about the API by modifying the quickstart
project.
</p>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h4class="title">
<aname="building.no_install_quickstart.modifying_the_example_project"></a><aclass="link"href="no_install_quickstart.html#building.no_install_quickstart.modifying_the_example_project"title="Modifying the Example Project">Modifying
If you're content to keep your extension module forever in one source file
called <codeclass="computeroutput"><spanclass="identifier">extending</span><spanclass="special">.</span><spanclass="identifier">cpp</span></code>, inside your Boost.Python distribution,
and import it forever as <codeclass="computeroutput"><spanclass="identifier">extending</span></code>,
then you can stop here. However, it's likely that you will want to make
a few changes. There are a few things you can do without having to learn
<ahref="http://www.boost.org/build"target="_top">Boost.Build</a> in depth.
</p>
<p>
The project you just built is specified in two files in the current directory:
<codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">-</span><spanclass="identifier">build</span><spanclass="special">.</span><spanclass="identifier">jam</span></code>, which tells <codeclass="computeroutput"><spanclass="identifier">bjam</span></code>
where it can find the interpreted code of the Boost build system, and
<codeclass="computeroutput"><spanclass="identifier">Jamroot</span></code>, which describes
the targets you just built. These files are heavily commented, so they
should be easy to modify. Take care, however, to preserve whitespace. Punctuation
such as <codeclass="computeroutput"><spanclass="special">;</span></code> will not be recognized
as intended by <codeclass="computeroutput"><spanclass="identifier">bjam</span></code> if
it is not surrounded by whitespace.
</p>
<divclass="section">
<divclass="titlepage"><div><div><h5class="title">
<aname="building.no_install_quickstart.modifying_the_example_project.relocate_the_project"></a><aclass="link"href="no_install_quickstart.html#building.no_install_quickstart.modifying_the_example_project.relocate_the_project"title="Relocate the Project">Relocate
the Project</a>
</h5></div></div></div>
<p>
You'll probably want to copy this project elsewhere so you can change
it without modifying your Boost distribution. To do that, simply
</p>
<p>
a. copy the entire <codeclass="computeroutput"><spanclass="identifier">example</span><spanclass="special">/</span><spanclass="identifier">quickstart</span><spanclass="special">/</span></code> directory into a new directory.
</p>
<p>
b. In the new copies of <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">-</span><spanclass="identifier">build</span><spanclass="special">.</span><spanclass="identifier">jam</span></code>
and <codeclass="computeroutput"><spanclass="identifier">Jamroot</span></code>, locate the
relative path near the top of the file that is clearly marked by a comment,
and edit that path so that it refers to the same directory your Boost
distribution as it referred to when the file was in its original location
in the <codeclass="computeroutput"><spanclass="identifier">example</span><spanclass="special">/</span><spanclass="identifier">quickstart</span><spanclass="special">/</span></code>
directory.
</p>
<p>
For example, if you moved the project from <codeclass="computeroutput"><spanclass="special">/</span><spanclass="identifier">home</span><spanclass="special">/</span><spanclass="identifier">dave</span><spanclass="special">/</span><spanclass="identifier">boost_1_34_0</span><spanclass="special">/</span><spanclass="identifier">libs</span><spanclass="special">/</span><spanclass="identifier">python</span><spanclass="special">/</span><spanclass="identifier">example</span><spanclass="special">/</span><spanclass="identifier">quickstart</span></code> to <codeclass="computeroutput"><spanclass="special">/</span><spanclass="identifier">home</span><spanclass="special">/</span><spanclass="identifier">dave</span><spanclass="special">/</span><spanclass="identifier">my</span><spanclass="special">-</span><spanclass="identifier">project</span></code>, you could change the first
path in <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">-</span><spanclass="identifier">build</span><spanclass="special">.</span><spanclass="identifier">jam</span></code> from
<aname="building.no_install_quickstart.modifying_the_example_project.add_new_or_change_names_of_exist"></a><aclass="link"href="no_install_quickstart.html#building.no_install_quickstart.modifying_the_example_project.add_new_or_change_names_of_exist"title="Add New or Change Names of Existing Source Files">Add
New or Change Names of Existing Source Files</a>
</h5></div></div></div>
<p>
The names of additional source files involved in building your extension
module or embedding application can be listed in <codeclass="computeroutput"><spanclass="identifier">Jamroot</span></code>
right alongside <codeclass="computeroutput"><spanclass="identifier">extending</span><spanclass="special">.</span><spanclass="identifier">cpp</span></code>
or <codeclass="computeroutput"><spanclass="identifier">embedding</span><spanclass="special">.</span><spanclass="identifier">cpp</span></code> respectively. Just be sure to leave
Naturally, if you want to change the name of a source file you can tell
Boost.Build about it by editing the name in <codeclass="computeroutput"><spanclass="identifier">Jamroot</span></code>.
</p>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h5class="title">
<aname="building.no_install_quickstart.modifying_the_example_project.change_the_name_of_your_extensio"></a><aclass="link"href="no_install_quickstart.html#building.no_install_quickstart.modifying_the_example_project.change_the_name_of_your_extensio"title="Change the Name of your Extension Module">Change
the Name of your Extension Module</a>
</h5></div></div></div>
<p>
The name of the extension module is determined by two things:
the name in <codeclass="computeroutput"><spanclass="identifier">Jamroot</span></code>
immediately following <codeclass="computeroutput"><spanclass="identifier">python</span><spanclass="special">-</span><spanclass="identifier">extension</span></code>,
and
</li>
<liclass="listitem">
the name passed to <codeclass="computeroutput"><spanclass="identifier">BOOST_PYTHON_MODULE</span></code>
in <codeclass="computeroutput"><spanclass="identifier">extending</span><spanclass="special">.</span><spanclass="identifier">cpp</span></code>.
</li>
</ol></div>
<p>
To change the name of the extension module from <codeclass="computeroutput"><spanclass="identifier">extending</span></code>
to <codeclass="computeroutput"><spanclass="identifier">hello</span></code>, you'd edit
<aname="building.notes_for_mingw_and_cygwin_with_"></a><aclass="link"href="notes_for_mingw_and_cygwin_with_.html"title="Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users">Notes for
MinGW (and Cygwin with -mno-cygwin) GCC Users</a>
</h3></div></div></div>
<p>
If you are using a version of Python prior to 2.4.1 with a MinGW prior to
3.0.0 (with binutils-2.13.90-20030111-1), you will need to create a MinGW-compatible
version of the Python library; the one shipped with Python will only work
with a Microsoft-compatible linker. Follow the instructions in the “Non-Microsoft”
section of the “Building Extensions: Tips And Tricks” chapter in <ahref="https://docs.python.org/2/install/index.html"target="_top">Installing Python Modules</a>
to create <codeclass="computeroutput"><spanclass="identifier">libpythonXX</span><spanclass="special">.</span><spanclass="identifier">a</span></code>, where <codeclass="computeroutput"><spanclass="identifier">XX</span></code>
corresponds to the major and minor version numbers of your Python installation.
Python can be built in a special “python debugging” configuration that
adds extra checks and instrumentation that can be very useful for developers
of extension modules. The data structures used by the debugging configuration
contain additional members, so <spanclass="bold"><strong>a Python executable
built with python debugging enabled cannot be used with an extension module
or library compiled without it, and vice-versa.</strong></span>
</p>
<p>
Since pre-built “python debugging” versions of the Python executable
and libraries are not supplied with most distributions of Python, <ahref="#ftn.building.python_debugging_builds.f0"class="footnote"name="building.python_debugging_builds.f0"><supclass="footnote">[5]</sup></a> and we didn't want to force our users to build them, Boost.Build
does not automatically enable python debugging in its <codeclass="computeroutput"><spanclass="identifier">debug</span></code>
build variant (which is the default). Instead there is a special build property
called <codeclass="computeroutput"><spanclass="identifier">python</span><spanclass="special">-</span><spanclass="identifier">debugging</span></code> that, when used as a build property,
will define the right preprocessor symbols and select the right libraries
to link with.
</p>
<p>
On unix-variant platforms, the debugging versions of Python's data structures
will only be used if the symbol <codeclass="computeroutput"><spanclass="identifier">Py_DEBUG</span></code>
is defined. On many windows compilers, when extension modules are built with
the preprocessor symbol <codeclass="computeroutput"><spanclass="identifier">_DEBUG</span></code>,
Python defaults to force linking with a special debugging version of the
Python DLL. Since that symbol is very commonly used even when Python is not
when <codeclass="computeroutput"><spanclass="identifier">Python</span><spanclass="special">.</span><spanclass="identifier">h</span></code> is #included from <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">/</span><spanclass="identifier">python</span><spanclass="special">/</span><spanclass="identifier">detail</span><spanclass="special">/</span><spanclass="identifier">wrap_python</span><spanclass="special">.</span><spanclass="identifier">hpp</span></code> -
<spanclass="bold"><strong>Boost.Python</strong></span> uses several configuration
macros in <codeclass="computeroutput"><spanclass="special"><</span><spanclass="identifier">boost</span><spanclass="special">/</span><spanclass="identifier">config</span><spanclass="special">.</span><spanclass="identifier">hpp</span><spanclass="special">></span></code>, as well as configuration macros meant
to be supplied by the application. These macros are documented here.
</p>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h4class="title">
<aname="configuration.configuration.application_defined_macros"></a><aclass="link"href="configuration.html#configuration.configuration.application_defined_macros"title="Application Defined Macros">Application
Defined Macros</a>
</h4></div></div></div>
<p>
These are the macros that may be defined by an application using Boost.Python.
Note that if you extend a strict interpretation of the C++ standard to
cover dynamic libraries, using different values of these macros when compiling
different libraries (including extension modules and the Boost.Python library
itself) is a violation of the <aclass="link"href="glossary.html#odr">ODR</a>. However,
we know of no C++ implementations on which this particular violation is
detectable or causes any problems.
</p>
<divclass="informaltable"><tableclass="table">
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead><tr>
<th>
<p>
Macro
</p>
</th>
<th>
<p>
Default
</p>
</th>
<th>
<p>
Meaning
</p>
</th>
</tr></thead>
<tbody>
<tr>
<td>
<p>
BOOST_PYTHON_MAX_ARITY
</p>
</td>
<td>
<p>
15
</p>
</td>
<td>
<p>
The maximum arity of any function, member function, or constructor
to be wrapped, invocation of a Boost.Python function wich is
specified as taking arguments x1, x2,...Xn. This includes, in
particular, callback mechanisms such as object::operator()(...)
or call_method<R>(... ).
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_MAX_BASES
</p>
</td>
<td>
<p>
10
</p>
</td>
<td>
<p>
The maximum number of template arguments to the <codeclass="computeroutput"><spanclass="identifier">bases</span><spanclass="special"><...></span></code>
class template, which is used to specify the bases of a wrapped
C++ class..
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_STATIC_MODULE
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined, prevents your module initialization function from
being treated as an exported symbol on platforms which support
that distinction in-code
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_ENABLE_CDECL
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined, allows functions using the <codeclass="computeroutput"><spanclass="identifier">__cdecl</span></code>
calling convention to be wrapped.
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_ENABLE_STDCALL
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined, allows functions using the <codeclass="computeroutput"><spanclass="identifier">__stdcall</span></code>
calling convention to be wrapped.
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_ENABLE_FASTCALL
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined, allows functions using the <codeclass="computeroutput"><spanclass="identifier">__fastcall</span></code>
calling convention to be wrapped.
</p>
</td>
</tr>
</tbody>
</table></div>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h4class="title">
<aname="configuration.configuration.library_defined_defined_macros"></a><aclass="link"href="configuration.html#configuration.configuration.library_defined_defined_macros"title="Library Defined Defined Macros">Library
Defined Defined Macros</a>
</h4></div></div></div>
<p>
These macros are defined by <spanclass="bold"><strong>Boost.Python</strong></span>
and are implementation details of interest only to implementors and those
porting to new platforms.
</p>
<divclass="informaltable"><tableclass="table">
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead><tr>
<th>
<p>
Macro
</p>
</th>
<th>
<p>
Default
</p>
</th>
<th>
<p>
Meaning
</p>
</th>
</tr></thead>
<tbody>
<tr>
<td>
<p>
BOOST_PYTHON_TYPE_ID_NAME
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined, this indicates that the type_info comparison across
shared library boundaries does not work on this platform. In
other words, if shared-lib-1 passes <codeclass="computeroutput"><spanclass="keyword">typeid</span><spanclass="special">(</span><spanclass="identifier">T</span><spanclass="special">)</span></code> to a function in shared-lib-2
which compares it to <codeclass="computeroutput"><spanclass="keyword">typeid</span><spanclass="special">(</span><spanclass="identifier">T</span><spanclass="special">)</span></code>, that comparison may return
<codeclass="computeroutput"><spanclass="keyword">false</span></code>. If this macro
is #defined, Boost.Python uses and compares <codeclass="computeroutput"><spanclass="keyword">typeid</span><spanclass="special">(</span><spanclass="identifier">T</span><spanclass="special">).</span><spanclass="identifier">name</span><spanclass="special">()</span></code> instead of using and comparing
the <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">type_info</span></code> objects directly.
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_NO_PY_SIGNATURES
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined for a module no pythonic signatures are generated
for the docstrings of the module functions, and no python type
is associated with any of the converters registered by the module.
This also reduces the binary size of the module by about 14%
(gcc compiled). If defined for the boost_python runtime library,
the default for the <codeclass="computeroutput"><spanclass="identifier">docstring_options</span><spanclass="special">.</span><spanclass="identifier">enable_py_signatures</span><spanclass="special">()</span></code> is set to <codeclass="computeroutput"><spanclass="keyword">false</span></code>.
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_SUPPORTS_PY_SIGNATURES
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>defined</em></span> if <codeclass="computeroutput"><spanclass="identifier">BOOST_PYTHON_NO_PY_SIGNATURES</span></code>
is <spanclass="emphasis"><em>undefined</em></span>
</p>
</td>
<td>
<p>
This macro is defined to enable a smooth transition from older
Boost.Python versions which do not support pythonic signatures.
For example usage see here.
</p>
</td>
</tr>
<tr>
<td>
<p>
BOOST_PYTHON_PY_SIGNATURES_PROPER_INIT_SELF_TYPE
</p>
</td>
<td>
<p>
<spanclass="emphasis"><em>not defined</em></span>
</p>
</td>
<td>
<p>
If defined the python type of <codeclass="computeroutput"><spanclass="identifier">__init__</span></code>
method "self" parameters is properly generated, otherwise
object is used. It is undefined by default because it increases
the binary size of the module by about 14% (gcc compiled).
<linkrel="next"href="faq/i_m_getting_the_attempt_to_retur.html"title="I'm getting the "attempt to return dangling reference" error. What am I doing wrong?">
<aname="faq.how_can_i_wrap_a_function_which_"></a><aclass="link"href="faq.html#faq.how_can_i_wrap_a_function_which_"title="How can I wrap a function which takes a function pointer as an argument?">How can I wrap
a function which takes a function pointer as an argument?</a>
</h3></div></div></div>
<p>
If what you're trying to do is something like this:
<aname="faq.compilation_takes_too_much_time_"></a><aclass="link"href="compilation_takes_too_much_time_.html"title="Compilation takes too much time and eats too much memory! What can I do to make it faster?">Compilation takes
too much time and eats too much memory! What can I do to make it faster?</a>
</h3></div></div></div>
<p>
Please refer to the <codeclass="computeroutput"><spanclass="identifier">Reducing</span><spanclass="identifier">Compiling</span><spanclass="identifier">Time</span></code>
section in the <ahref="../tutorial/index.html"target="_top">Tutorial</a>.
<aname="faq.does_boost_python_work_with_mac_"></a><aclass="link"href="does_boost_python_work_with_mac_.html"title="Does Boost.Python work with Mac OS X?">Does Boost.Python
work with Mac OS X?</a>
</h3></div></div></div>
<p>
It is known to work under 10.2.8 and 10.3 using Apple's gcc 3.3 compiler:
The last command requires root privileges because the target directory is
<codeclass="computeroutput"><spanclass="special">/</span><spanclass="identifier">Library</span><spanclass="special">/</span><spanclass="identifier">Frameworks</span><spanclass="special">/</span><spanclass="identifier">Python</span><spanclass="special">.</span><spanclass="identifier">framework</span><spanclass="special">/</span><spanclass="identifier">Versions</span><spanclass="special">/</span><spanclass="number">2.3</span></code>. However,
the installation does not interfere with the Python version that ships with
10.2.8.
</p>
<p>
It is also crucial to increase the <codeclass="computeroutput"><spanclass="identifier">stacksize</span></code>
If the <codeclass="computeroutput"><spanclass="identifier">stacksize</span></code> is too small
the build might crash with internal compiler errors.
</p>
<p>
Sometimes Apple's compiler exhibits a bug by printing an error like the following
while compiling a <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">::</span><spanclass="identifier">python</span><spanclass="special">::</span><spanclass="identifier">class_</span><spanclass="special"><</span><spanclass="identifier">your_type</span><spanclass="special">></span></code>
<spanclass="keyword">dynamic_cast</span><spanclass="error">`</span><spanclass="identifier">p</span><spanclass="char">' (of type `struct cctbx::boost_python::<unnamed>::add_pair*
We do not know a general workaround, but if the definition of <codeclass="computeroutput"><spanclass="identifier">your_type</span></code> can be modified the following
was found to work in all cases encountered so far:
<aname="faq.error_c2064_term_does_not_evalua"></a><aclass="link"href="error_c2064_term_does_not_evalua.html"title="error C2064: term does not evaluate to a function taking 2 arguments">error C2064: term
does not evaluate to a function taking 2 arguments</a>
</h3></div></div></div>
<p>
<spanclass="emphasis"><em>Niall Douglas provides these notes:</em></span>
</p>
<p>
If you see Microsoft Visual C++ 7.1 (MS Visual Studio .NET 2003) issue an
error message like the following it is most likely due to a bug in the compiler:
The bug is related to the <codeclass="computeroutput"><spanclass="keyword">throw</span><spanclass="special">()</span></code> modifier. As a workaround cast off the
If you find that a <codeclass="computeroutput"><spanclass="identifier">class_</span><spanclass="special"><...></span></code> declaration can't fit in
a single source file without triggering the error, you can always pass
a reference to the <codeclass="computeroutput"><spanclass="identifier">class_</span></code>
object to a function in another source file, and call some of its member
functions (e.g. <codeclass="computeroutput"><spanclass="special">.</span><spanclass="identifier">def</span><spanclass="special">(...)</span></code>) in the auxilliary source file:
<aname="faq.how_can_i_automatically_convert_"></a><aclass="link"href="how_can_i_automatically_convert_.html"title="How can I automatically convert my custom string type to and from a Python string?">How can I automatically
convert my custom string type to and from a Python string?</a>
</h3></div></div></div>
<p>
<spanclass="emphasis"><em>Ralf W. Grosse-Kunstleve provides these notes:</em></span>
</p>
<p>
Below is a small, self-contained demo extension module that shows how to
<aname="faq.how_can_i_find_the_existing_pyob"></a><aclass="link"href="how_can_i_find_the_existing_pyob.html"title="How can I find the existing PyObject that holds a C++ object?">How can I find
the existing PyObject that holds a C++ object?</a>
<spanclass="identifier">X</span><spanclass="special">*</span><spanclass="identifier">f</span><spanclass="special">();</span><spanclass="comment">// known to return Xs that are managed by Python objects</span>
Of course, if X has no virtual functions you'll have to use <codeclass="computeroutput"><spanclass="keyword">static_cast</span></code> instead of <codeclass="computeroutput"><spanclass="keyword">dynamic_cast</span></code>
with no runtime check that it's valid. This approach also only works if the
<codeclass="computeroutput"><spanclass="identifier">X</span></code> object was constructed
from Python, because <codeclass="computeroutput"><spanclass="identifier">X</span></code>s constructed
from C++ are of course never <codeclass="computeroutput"><spanclass="identifier">X_wrap</span></code>
objects.
</p>
<p>
Another approach to this requires you to change your C++ code a bit; if that's
an option for you it might be a better way to go. work we've been meaning
to get to anyway. When a <codeclass="computeroutput"><spanclass="identifier">shared_ptr</span><spanclass="special"><</span><spanclass="identifier">X</span><spanclass="special">></span></code>
is converted from Python, the shared_ptr actually manages a reference to
the containing Python object. When a shared_ptr<X> is converted back
to Python, the library checks to see if it's one of those "Python object
managers" and if so just returns the original Python object. So you
could just write <codeclass="computeroutput"><spanclass="identifier">object</span><spanclass="special">(</span><spanclass="identifier">p</span><spanclass="special">)</span></code> to get
the Python object back. To exploit this you'd have to be able to change the
C++ code you're wrapping so that it deals with shared_ptr instead of raw
pointers.
</p>
<p>
There are other approaches too. The functions that receive the Python object
that you eventually want to return could be wrapped with a thin wrapper that
records the correspondence between the object address and its containing
Python object, and you could have your f_wrap function look in that mapping
<linkrel="prev"href="how_can_i_find_the_existing_pyob.html"title="How can I find the existing PyObject that holds a C++ object?">
<linkrel="next"href="compilation_takes_too_much_time_.html"title="Compilation takes too much time and eats too much memory! What can I do to make it faster?">
<aname="faq.how_can_i_wrap_a_function_which0"></a><aclass="link"href="how_can_i_wrap_a_function_which0.html"title="How can I wrap a function which needs to take ownership of a raw pointer?">How can I wrap
a function which needs to take ownership of a raw pointer?</a>
</h3></div></div></div>
<p>
<spanclass="bold"><strong>Q:</strong></span> Part of an API that I'm wrapping goes
<aname="faq.how_can_i_wrap_functions_which_t"></a><aclass="link"href="how_can_i_wrap_functions_which_t.html"title="How can I wrap functions which take C++ containers as arguments?">How can I wrap
functions which take C++ containers as arguments?</a>
This can be moved to a template so that several types (<codeclass="computeroutput"><spanclass="keyword">double</span></code>, <codeclass="computeroutput"><spanclass="keyword">int</span></code>,
<codeclass="computeroutput"><spanclass="keyword">long</span></code>, etc.) can be wrapped
with the same code. This technique is used in the file <codeclass="computeroutput"><spanclass="identifier">scitbx</span><spanclass="special">/</span><spanclass="identifier">include</span><spanclass="special">/</span><spanclass="identifier">scitbx</span><spanclass="special">/</span><spanclass="identifier">array_family</span><spanclass="special">/</span><spanclass="identifier">boost_python</span><spanclass="special">/</span><spanclass="identifier">flex_wrapper</span><spanclass="special">.</span><spanclass="identifier">h</span></code> in the "scitbx" package.
The file could easily be modified for wrapping <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">vector</span><spanclass="special"><></span></code> instantiations. This type of
C++/Python binding is most suitable for containers that may contain a
large number of elements (>10000).
</li>
<liclass="listitem">
<p>
Using custom rvalue converters. Boost.Python "rvalue converters"
match function signatures such as:
</p>
<preclass="programlisting"><spanclass="keyword">void</span><spanclass="identifier">foo</span><spanclass="special">(</span><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">vector</span><spanclass="special"><</span><spanclass="keyword">double</span><spanclass="special">></span><spanclass="keyword">const</span><spanclass="special">&</span><spanclass="identifier">array</span><spanclass="special">);</span><spanclass="comment">// pass by const-reference</span>
<spanclass="keyword">void</span><spanclass="identifier">foo</span><spanclass="special">(</span><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">vector</span><spanclass="special"><</span><spanclass="keyword">double</span><spanclass="special">></span><spanclass="identifier">array</span><spanclass="special">);</span><spanclass="comment">// pass by value</span>
</pre>
Some custom rvalue converters are implemented in the file <codeclass="computeroutput"><spanclass="identifier">scitbx</span><spanclass="special">/</span><spanclass="identifier">include</span><spanclass="special">/</span><spanclass="identifier">scitbx</span><spanclass="special">/</span><spanclass="identifier">boost_python</span><spanclass="special">/</span><spanclass="identifier">container_conversions</span><spanclass="special">.</span><spanclass="identifier">h</span></code> This code can be used to convert
from C++ container types such as <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">vector</span><spanclass="special"><></span></code> or <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">list</span><spanclass="special"><></span></code> to Python tuples and vice versa.
A few simple examples can be found in the file <codeclass="computeroutput"><spanclass="identifier">scitbx</span><spanclass="special">/</span><spanclass="identifier">array_family</span><spanclass="special">/</span><spanclass="identifier">boost_python</span><spanclass="special">/</span><spanclass="identifier">regression_test_module</span><spanclass="special">.</span><spanclass="identifier">cpp</span></code>
Automatic C++ container <-> Python tuple conversions are most suitable
for containers of moderate size. These converters generate significantly
less object code compared to alternative 1 above.
</li>
</ol></div>
<p>
A disadvantage of using alternative 2 is that operators such as arithmetic
+,-,*,/,% are not available. It would be useful to have custom rvalue converters
that convert to a "math_array" type instead of tuples. This is
currently not implemented but is possible within the framework of Boost.Python
V2 as it will be released in the next couple of weeks. [ed.: this was posted
on 2002/03/10]
</p>
<p>
It would also be useful to also have "custom lvalue converters"
such as <codeclass="computeroutput"><spanclass="identifier">std</span><spanclass="special">::</span><spanclass="identifier">vector</span><spanclass="special"><></span></code>
<-> Python list. These converters would support the modification of
<linkrel="prev"href="compilation_takes_too_much_time_.html"title="Compilation takes too much time and eats too much memory! What can I do to make it faster?">
<linkrel="next"href="error_c2064_term_does_not_evalua.html"title="error C2064: term does not evaluate to a function taking 2 arguments">
<aname="faq.how_do_i_create_sub_packages_usi"></a><aclass="link"href="how_do_i_create_sub_packages_usi.html"title="How do I create sub-packages using Boost.Python?">How do I create
sub-packages using Boost.Python?</a>
</h3></div></div></div>
<p>
Please refer to the <codeclass="computeroutput"><spanclass="identifier">Creating</span><spanclass="identifier">Packages</span></code> section in the <ahref="../tutorial/index.html"target="_top">Tutorial</a>.
<aname="faq.how_do_i_debug_my_python_extensi"></a><aclass="link"href="how_do_i_debug_my_python_extensi.html"title="How do I debug my Python extensions?">How do I debug
my Python extensions?</a>
</h3></div></div></div>
<p>
Greg Burley gives the following answer for Unix GCC users:
If you are launching your extension module tests with <ahref="http://www.boost.org/build"target="_top">Boost.Build</a>
using the <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">-</span><spanclass="identifier">python</span><spanclass="special">-</span><spanclass="identifier">runtest</span></code> rule, you can ask it to launch
your debugger for you by adding "--debugger=<spanclass="emphasis"><em>debugger</em></span>"
It can also be extremely useful to add the <codeclass="computeroutput"><spanclass="special">-</span><spanclass="identifier">d</span><spanclass="special">+</span><spanclass="number">2</span></code>
option when you run your test, because Boost.Build will then show you the
exact commands it uses to invoke it. This will invariably involve setting
up PYTHONPATH and other important environment variables such as LD_LIBRARY_PATH
which may be needed by your debugger in order to get things to work right.
<aname="faq.i_m_getting_the_attempt_to_retur"></a><aclass="link"href="i_m_getting_the_attempt_to_retur.html"title="I'm getting the "attempt to return dangling reference" error. What am I doing wrong?">I'm getting the
"attempt to return dangling reference" error. What am I doing wrong?</a>
</h3></div></div></div>
<p>
That exception is protecting you from causing a nasty crash. It usually happens
In this case, the Python method invoked by <codeclass="computeroutput"><spanclass="identifier">call_method</span></code>
constructs a new Python object. You're trying to return a reference to a
C++ object (an instance of <codeclass="computeroutput"><spanclass="keyword">class</span><spanclass="identifier">period</span></code>) contained within and owned by that
Python object. Because the called method handed back a brand new object,
the only reference to it is held for the duration of <codeclass="computeroutput"><spanclass="identifier">get_floating_frequency</span><spanclass="special">()</span></code> above. When the function returns, the Python
object will be destroyed, destroying the instance of <codeclass="computeroutput"><spanclass="keyword">class</span>
<spanclass="identifier">period</span></code>, and leaving the returned
reference dangling. That's already undefined behavior, and if you try to
do anything with that reference you're likely to cause a crash. Boost.Python
detects this situation at runtime and helpfully throws an exception instead
<aname="faq.is_boost_python_thread_aware_com"></a><aclass="link"href="is_boost_python_thread_aware_com.html"title="Is Boost.Python thread-aware/compatible with multiple interpreters?">Is Boost.Python
thread-aware/compatible with multiple interpreters?</a>
</h3></div></div></div>
<p>
<spanclass="emphasis"><em>Niall Douglas provides these notes:</em></span>
</p>
<p>
The quick answer to this is: no.
</p>
<p>
The longer answer is that it can be patched to be so, but it's complex. You
will need to add custom lock/unlock wrapping of every time your code enters
Boost.Python (particularly every virtual function override) plus heavily
modify <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">/</span><spanclass="identifier">python</span><spanclass="special">/</span><spanclass="identifier">detail</span><spanclass="special">/</span><spanclass="identifier">invoke</span><spanclass="special">.</span><spanclass="identifier">hpp</span></code> with custom unlock/lock wrapping of
every time Boost.Python enters your code. You must furthermore take care
to <spanclass="emphasis"><em>not</em></span> unlock/lock when Boost.Python is invoking iterator
changes via <codeclass="computeroutput"><spanclass="identifier">invoke</span><spanclass="special">.</span><spanclass="identifier">hpp</span></code>.
</p>
<p>
There is a patched <codeclass="computeroutput"><spanclass="identifier">invoke</span><spanclass="special">.</span><spanclass="identifier">hpp</span></code> posted
on the C++-SIG mailing list archives and you can find a real implementation
of all the machinery necessary to fully implement this in the TnFOX project
at <ahref="http://sourceforge.net/projects/tnfox/"target="_top">this</a> SourceForge
<linkrel="prev"href="i_m_getting_the_attempt_to_retur.html"title="I'm getting the "attempt to return dangling reference" error. What am I doing wrong?">
<linkrel="next"href="how_can_i_wrap_functions_which_t.html"title="How can I wrap functions which take C++ containers as arguments?">
will make an instance with storage for one of your objects, <codeclass="computeroutput"><spanclass="identifier">size</span><spanclass="special">=</span><spanclass="identifier">base_size</span><spanclass="special">+</span><spanclass="number">12</span><spanclass="special">*</span><spanclass="keyword">sizeof</span><spanclass="special">(</span><spanclass="keyword">double</span><spanclass="special">)</span></code>.
<aname="faq.why_doesn_t_my_operator_work"></a><aclass="link"href="why_doesn_t_my_operator_work.html"title="Why doesn't my *= operator work?">Why doesn't my <codeclass="computeroutput"><spanclass="special">*=</span></code> operator work?</a>
</h3></div></div></div>
<p>
<spanclass="bold"><strong>Q:</strong></span><spanclass="emphasis"><em>I have exported my class to
python, with many overloaded operators. it works fine for me except the
<codeclass="computeroutput"><spanclass="special">*=</span></code> operator. It always tells
me "can't multiply sequence with non int type". If I use <codeclass="computeroutput"><spanclass="identifier">p1</span><spanclass="special">.</span><spanclass="identifier">__imul__</span><spanclass="special">(</span><spanclass="identifier">p2</span><spanclass="special">)</span></code>
instead of <codeclass="computeroutput"><spanclass="identifier">p1</span><spanclass="special">*=</span>
<spanclass="identifier">p2</span></code>, it successfully executes my
code. What's wrong with me?</em></span>
</p>
<p>
<spanclass="bold"><strong>A:</strong></span> There's nothing wrong with you. This
is a bug in Python 2.2. You can see the same effect in Pure Python (you can
learn a lot about what's happening in Boost.Python by playing with new-style
<aname="faq.why_is_my_automatic_to_python_co"></a><aclass="link"href="why_is_my_automatic_to_python_co.html"title="Why is my automatic to-python conversion not being found?">Why is my automatic
to-python conversion not being found?</a>
</h3></div></div></div>
<p>
<spanclass="emphasis"><em>Niall Douglas provides these notes:</em></span>
</p>
<p>
If you define custom converters similar to the ones shown above the <codeclass="computeroutput"><spanclass="identifier">def_readonly</span><spanclass="special">()</span></code>
and <codeclass="computeroutput"><spanclass="identifier">def_readwrite</span><spanclass="special">()</span></code>
member functions provided by <codeclass="computeroutput"><spanclass="identifier">boost</span><spanclass="special">::</span><spanclass="identifier">python</span><spanclass="special">::</span><spanclass="identifier">class_</span></code>
for direct access to your member data will not work as expected. This is
because <codeclass="computeroutput"><spanclass="identifier">def_readonly</span><spanclass="special">(</span><spanclass="string">"bar"</span><spanclass="special">,&</span><spanclass="identifier">foo</span><spanclass="special">::</span><spanclass="identifier">bar</span><spanclass="special">)</span></code> is equivalent to:
d="m 131.82255,113.25481 c 14.13897,0 13.25604,-6.13151 13.25604,-6.13151 l -0.0157,-6.35219 -13.49248,0 0,-1.907219 18.85164,0 c 0,0 9.04754,1.026071 9.04754,-13.240285 0,-14.266357 -7.89689,-13.760451 -7.89689,-13.760451 l -4.71291,0 0,6.620147 c 0,0 0.25403,7.896881 -7.77079,7.896881 -8.02483,0 -13.38214,0 -13.38214,0 0,0 -7.5186,-0.121529 -7.5186,7.266406 0,7.387911 0,12.215731 0,12.215731 0,0 -1.14153,7.39249 13.63434,7.39249 z m 7.43977,-4.27157 c -1.3424,0 -2.42738,-1.08499 -2.42738,-2.42739 0,-1.3424 1.08498,-2.42739 2.42738,-2.42739 1.34241,0 2.42739,1.08499 2.42739,2.42739 1e-5,1.3424 -1.08498,2.42739 -2.42739,2.42739 z"
id="path8620"/><text
xml:space="preserve"
style="font-style:italic;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:131.83750916px;line-height:100%;font-family:'Nimbus Sans L';-inkscape-font-specification:'Nimbus Sans L, Bold Italic';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#00507f;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.