From romany at actimize.com Mon Sep 1 14:06:13 2003
From: romany at actimize.com (Roman Yakovenko)
Date: Mon, 1 Sep 2003 15:06:13 +0300
Subject: [C++-sig] module too big.
Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B0F@exchange.adrembi.com>
Hi Nicodemus. Thanks for your quick and helpfull responce.
But it didn't help me in all cases. The reason is simple my compiler
( VC 6.0 SP 5 ) is too limited. I had to devide even single class
( 15 functions ) to 2 files. Thanks a lot for good tool.
Roman.
> -----Original Message-----
> From: Nicodemus [mailto:nicodemus at globalite.com.br]
> Sent: Friday, August 29, 2003 1:06 AM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] module too big.
>
>
> Hi Roman,
>
> Roman Yakovenko wrote:
>
> >Hi. Using Pyste I succedded to generate wrapper for my library.
> >The file I got is 4000 lines. My question is how can I devide
> >this file to a few small ones ?
> >
> >
>
> The support for big wrappers has improved a lot in the last
> few weeks,
> thanks to a combinated effort of Prabhu Ramachandran and myself. We
> discussed a lot, shared lots of code, and came up with a
> solution that
> he and I are quite happy with it. 8)
> I didn't write the documentation about it, thought, so I will
> describe
> the procedure here. Let's use this class hierarchy as an example:
>
> // A.h
> struct A { /* ... */ };
>
> // B.h
> #include "A.h"
> struct B: A { /* ... */ };
>
> // C.h
> #include "B.h"
> struct C: B { /* ... */ };
>
> First thing, you must divide your classes in multiple Pyste
> files. Mind
> you, Boost.Python needs base classes to be instantiated
> before derived
> classes, and Pyste did that automatically for you, but not
> anymore, so
> you have to do it by hand. Let's write one Pyste file for our
> library then:
>
>
> # mylib.pyste
> Class("A", "A.h")
> Class("B", "B.h")
> Class("C", "C.h")
>
>
> Notice that the base class, A, has been declared first. This is the
> simplest usage. We use this command line:
>
> pyste.py --module=mylib mylib.pyste
>
> This will generate a file named "mylib.cpp" in the current directory
> with all the classes exported.
>
> Now suppose this file is too big (as is your case) and it
> takes ages to
> compile, plus after any little change you do in both your code or the
> Pyste file you will have to re-generate the wrapper code
> (which can take
> a while) and recompile it (which taks *quite* a while 8) ).
>
> The first step to solve this problem is to split your classes in
> multiple Pyste files. Here, let's put A and B in their own Pyste file
> (AB.pyste), and put C in another (C.pyste). But we have to
> declare also
> that C.pyste depends on AB.pyste, so that Pyste knows that A
> and B are
> also being exported to generate the correct code. Here are
> the contents
> of then:
>
>
> # AB.pyste
> Class("A", "A.h")
> Class("B", "B.h")
>
> # C.pyste
> Import("AB.pyste") # that's how we declare the dependency
> Class("C", "C.h")
>
>
> Ok, now we have to generate the code. You use the --multiple flag to
> specify that your are sharing your wrapping code across
> multiple cpp files:
>
> pyste.py --multiple --module=mylib AB.pyste
>
> This will generate the file mylib/_AB.cpp.
>
> pyste.py --multiple --module=mylib C.pyste
>
> This will generate the file mylib/_C.cpp.
>
> Those files contain the definition of the classes, but they don't
> declare BOOST_PYTHON_MODULE. This is done in a separate file,
> that you
> create with this command line:
>
> pyste.py --multiple --module=mylib --generate-main
> AB.pyste C.pyste
>
> This will generate the file mylib/_main.cpp. To correctly
> generate it,
> you have to pass in the command line *all* the Pyste files of your
> library. Fortunately, the generation of this file is almost
> instantly. ;)
>
> Now, we have in the mylib folder all the files needed by our library:
>
> _AB.cpp
> _C.cpp
> _main.cpp
>
> You now just compile them all normaly to object files, and
> link them all
> together. You will have an extension module as before, but with a few
> advantages:
>
> * If you change a header file used by a Pyste file, only the
> corresponding cpp of that Pyste file will have to be regenerated and
> recompiled, the rest stays intact.
> * Compile time will normally be reduced, since with very
> big files
> the memory consumption by the compiler gets out of hand.
>
> There's a feature that will also speed-up the re-generation of the
> wrappers (not compilation), the possibility to create Pyste
> caches. You
> just have to add a new option to the command lines above:
> "--cache-dir=
". In the directory specified, Pyste
> will cache
> the output by GCCXML, which should give a boost of about 3 to 4 times
> over the normal usage. Example:
>
> pyste.py --multiple --module=mylib --cache-dir=cache C.pyste
>
> This will generate, besides mylib/_C.cpp, a file named
> cache/C.pystec.
> The next time you run this same command, it should create the
> wrappers
> much quicker than before. But note that C.pystec depends on all the
> headers of the declarations in C.pyste, so if you change C.h,
> you should
> re-generate the cache. You can either delete C.pystec, or run:
>
> pyste.py --multiple --module=mylib --cache-dir=cache
> --only-create-cache C.pyste
>
> This will recreate the C.pystec file, but will not generate
> any wrapper
> code.
>
>
> Whew! Hope that gets you moving! 8)
> Feel free to ask any questions you may have!
>
> Regards,
> Nicodemus.
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
From arnaud.picard at edfgdf.fr Mon Sep 1 18:58:29 2003
From: arnaud.picard at edfgdf.fr (Arnaud PICARD)
Date: Mon, 1 Sep 2003 18:58:29 +0200
Subject: [C++-sig] Cross module definition
Message-ID:
Hello,
As I've already mentionned, I still have problems with cross def.
Here you'll find an example I've used to test a method. I'm not sure I've
done it right (actually I guess it's false since I can't get it to work
properly)
So, in these modules, I have define one as ModuleA and the other as
ModuleB.
They are AFAIK well written.
If I import them under python, and define c = ModuleA.Cmplx( 1., 0. ), b =
ModuleB.Printer(), and then try b.print1( c ) or b.print2( c ) it won't
work.
From arnaud.picard at edfgdf.fr Mon Sep 1 19:05:54 2003
From: arnaud.picard at edfgdf.fr (Arnaud PICARD)
Date: Mon, 1 Sep 2003 18:05:54 +0100
Subject: [C++-sig] Cross module definition
Message-ID:
Sorry, my latest mail was sent before I'd had time to complete it...
--------------------------
Hello,
As I've already mentionned, I still have problems with cross def.
Here you'll find an example I've used to test a method. I'm not sure I've
done it right (actually I guess it's false since I can't get it to work
properly)
So, in these modules, I have define one as ModuleA and the other as
ModuleB.
They are AFAIK well written.
If I import them under python, and define a = ModuleA.Cmplx( 1., 0. ), b =
ModuleB.Printer(), and then try b.print1( a ) or b.print2( a ) it won't
work.
If I define a with ModuleB instead of ModuleA it's running. That's still
the same problem I had with cross-module definition, with an example... If
I remove the line define_Cmplx() from ModuleD definition, I still cannot
get it to work even though I've imported first ModuleA then ModuleB.
What do I have to do so that I can pull the line "define_Cmplx()" out of my
ModuleB definition so that ModuleB's methods recognize my class Cmplx ?
I've understood what was reponsded last time, but I have not been able to
have it work properly...
Thanks in avance and still sorry for the former incomplete message,
Arnaud PICARD
EDF R&D, Clamart
Dept. SINETICS, I23
(See attached file: MyModules.tar.gz)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MyModules.tar.gz
Type: application/octet-stream
Size: 771 bytes
Desc: not available
URL:
From romany at actimize.com Tue Sep 2 06:20:07 2003
From: romany at actimize.com (Roman Yakovenko)
Date: Tue, 2 Sep 2003 07:20:07 +0300
Subject: [C++-sig] Pyste code generation.
Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B10@exchange.adrembi.com>
Hi Nicodemus. Today Pyste does not generate private virtual functions, right?
( in wrapper class of class that has private pure virtual )
May be it should be changed? Why ? I write wrapper for library that uses template
method pattern, where customization of method done by virtual private functions.
Here is the full artical http://www.gotw.ca/publications/mill18.htm.
Roman
From dave at boost-consulting.com Tue Sep 2 15:53:11 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 02 Sep 2003 09:53:11 -0400
Subject: [C++-sig] Re: Patch to add thread support to invoke function.
References: <001c01c39c31$a36f0b40$0200a8c0@barrack>
Message-ID:
"Lijun Qin" writes:
> Hi,
>
> I have made some changes to the invoke.hpp file, to add
>
> Py_UNBLOCK_THREADS
> result = f(...);
> Py_BLOCK_THREADS
>
> pair, this is need for too reasons:
> First, if the f(...) is a lengthy operation, it'll block all Python code to
> execute, this is not good,
> second, if f(...) function call some functions that will acquire the python
> global lock, it'll deadlock, one example is the COM inproc server using
> Pythoncom22.dll, every COM interface method will first call
> PyEval_AcquireThread, but the global lock has been held, so deadlock occur.
Hi Lijun,
I'm not ignoring your patches. Here's my reservation about accepting
this one, though: I don't think it represents a complete solution to
threading support in Boost.Python, and I'd like to solve the problem
all at once. On way in which this doesn't handle the problem is that
if f takes any object, str, dict, handle<>, etc. parameters by value,
the call may crash the interpreter as reference counts are changed
with threading unblocked. My guess is that the right solution is to
simply not unblock threads for those functions, since they are
hand-written with Boost.Python in mind and the author can unblock
threads manually if neccessary (with a "unguard" object). Another way
in which your patch is inadequate is that any code in Py_BLOCK_THREADS
will get skipped if f throws an exception, so we really need guard
objects which use RAII. Another way is that virtual functions which
call back into Python with call_method need to re-acquire the GIL
somehow -- it's not yet clear to me whether that should happen inside
or outside call_method.
The following are references to some threads in which these issues
have been discussed, should you wish to explore further:
http://aspn.activestate.com/ASPN/Mail/Message/1465959
http://aspn.activestate.com/ASPN/Mail/Message/1603259
http://aspn.activestate.com/ASPN/Mail/Message/1607050
http://aspn.activestate.com/ASPN/Mail/Message/1706806
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From djowel at gmx.co.uk Wed Sep 3 02:39:17 2003
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Wed, 3 Sep 2003 08:39:17 +0800
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
Message-ID: <00de01c371b4$51acd8c0$64646464@godzilla>
Raoul Gough wrote:
> "Joel de Guzman" writes:
> Well, I've had a go anyway. I've produced a container_proxy template
> that wraps a random-access container and provides access via element
> proxies. The element proxies provide an implicit conversion to the raw
> value type, and also a constructor from the raw value type, which
> means that it works with an unchanged[*1] vector_indexing_suite as
> follows:
>
> vector_indexing_suite, true>
This is great! Did the current tests pass with the new code?
> i.e. the wrapped vector with no proxy. This is functionally more or
> less equivalent to vector_indexing_suite, i.e. the raw
> vector *with* the proxy helper.
>
> [*1] Actually, it does require a minor patch to make
> vector_indexing_suite use the container's reference typedef rather
> than data_type &
>
> Note that I say "more or less" equivalent, since there seems to be a
> bug in the existing proxy support. Using vector, where
> IntWrapper is a simple int holder with optional tracing, the following
> snippet doesn't work correctly:
>
> copy = v[1]
> print "copy is %s, v[1] is %s" % (copy, v[1])
>
> v[1] = IntWrapper (5)
> print "copy is %s, v[1] is %s" % (copy, v[1])
>
> Sample output:
>
> copy is 3, v[1] is 3
> copy is 5, v[1] is 5 # Wrong - copy should remain unchanged
>
> The container_proxy wrapper fixes that problem (whatever it is,
> probably minor) but doesn't fix the following additional problem, that
> both versions exhibit:
Indeed. It's nice to hear that container_proxy fixed this.
> slice = v[1:2]
> print "slice[0] is %s, v[1] is %s" % (slice[0], v[1])
>
> v[1].increment()
> print "slice[0] is %s, v[1] is %s" % (slice[0], v[1])
>
> Sample output:
>
> slice[0] is 5, v[1] is 5
> slice[0] is 5, v[1] is 6 # Should be slice[0] is 6, v[1] is 6
>
> This may be a fundamental problem with how slices are returned.
> Compiler is gcc 3.3.1 (mingw special 20030804-1).
Right. slices are currently returned by value. I guess this is another
area to be explored. I think I know how to deal with it. Let's do
it when we refactor the slicing stuff. I think this is a good start. There
are lots of things to do and I certainly am glad that you can help. I've
already been bitten by the wholesale approach of the current indexing
suites (more on that later) that I really need to break it up sometime
soon!
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
From qinlj at solidshare.com Wed Sep 3 02:20:43 2003
From: qinlj at solidshare.com (Lijun Qin)
Date: Wed, 3 Sep 2003 08:20:43 +0800
Subject: [C++-sig] Re: Patch to add thread support to invoke function.
References: <001c01c39c31$a36f0b40$0200a8c0@barrack>
Message-ID: <002b01c371b1$3b138170$0200a8c0@barrack>
Hi,
I think a better solution is to give the user choice, I mean use a flag
which can be passed when calling 'def', such as
.def('f', f, enableThreadLock)
Currently I'm using boost.python to wrap WTL, and it has hundreds of
functions which are simple SendMessage wrappers, and many of them (I think
half of them, almost all 'write' operation) can cause callback into the
python code again, use the notify message such as WM_COMMAND, WM_NOTIFY. So
write wrapper for every one of them is not acceptable.
The callback will be implemented use call_method<> normally, but the thread
acquiring will not be done is call_method, it'll normally be done earlier in
the very point the control transferred from the 'outside world' to the
python extension module, in the Windows platform, this will normally at the
beginning of COM interface method, Window Procedure, or DLL exported
function (this is rare I think).
If we can implement the 'enableThreadLock' flag, but make it a 'false'
default, it'll be harmless to add this thread support into boost.python
code, but when needed, it'll be very convenience to have them.
I do agree that there should be a try catch block here, like:
Py_UNBLOCK_THREADS
try {
result = f(...);
} catch(...)
Py_BLOCK_THREADS
throw;
}
Py_BLOCK_THREADS
...
In my case, because SendMessage and COM method will never throw an
exception, so I ignored them in the last patch, for a complete solution,
it'll be better to do this.
Lijun Qin
http://www.solidshare.com
----- Original Message -----
From: "David Abrahams"
To:
Cc: "Lijun Qin"
Sent: Tuesday, September 02, 2003 9:53 PM
Subject: [C++-sig] Re: Patch to add thread support to invoke function.
> "Lijun Qin" writes:
>
> > Hi,
> >
> > I have made some changes to the invoke.hpp file, to add
> >
> > Py_UNBLOCK_THREADS
> > result = f(...);
> > Py_BLOCK_THREADS
> >
> > pair, this is need for too reasons:
> > First, if the f(...) is a lengthy operation, it'll block all Python code
to
> > execute, this is not good,
> > second, if f(...) function call some functions that will acquire the
python
> > global lock, it'll deadlock, one example is the COM inproc server using
> > Pythoncom22.dll, every COM interface method will first call
> > PyEval_AcquireThread, but the global lock has been held, so deadlock
occur.
>
> Hi Lijun,
>
> I'm not ignoring your patches. Here's my reservation about accepting
> this one, though: I don't think it represents a complete solution to
> threading support in Boost.Python, and I'd like to solve the problem
> all at once. On way in which this doesn't handle the problem is that
> if f takes any object, str, dict, handle<>, etc. parameters by value,
> the call may crash the interpreter as reference counts are changed
> with threading unblocked. My guess is that the right solution is to
> simply not unblock threads for those functions, since they are
> hand-written with Boost.Python in mind and the author can unblock
> threads manually if neccessary (with a "unguard" object). Another way
> in which your patch is inadequate is that any code in Py_BLOCK_THREADS
> will get skipped if f throws an exception, so we really need guard
> objects which use RAII. Another way is that virtual functions which
> call back into Python with call_method need to re-acquire the GIL
> somehow -- it's not yet clear to me whether that should happen inside
> or outside call_method.
>
> The following are references to some threads in which these issues
> have been discussed, should you wish to explore further:
>
> http://aspn.activestate.com/ASPN/Mail/Message/1465959
> http://aspn.activestate.com/ASPN/Mail/Message/1603259
> http://aspn.activestate.com/ASPN/Mail/Message/1607050
> http://aspn.activestate.com/ASPN/Mail/Message/1706806
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
From mike.thompson at day8.com.au Thu Sep 4 13:57:24 2003
From: mike.thompson at day8.com.au (Mike Thompson)
Date: Thu, 4 Sep 2003 21:57:24 +1000
Subject: [C++-sig] Test eom
Message-ID:
From mike.thompson at day8.com.au Thu Sep 4 07:19:40 2003
From: mike.thompson at day8.com.au (Mike Thompson)
Date: Thu, 4 Sep 2003 15:19:40 +1000
Subject: [C++-sig] "The filename or extension is too long"
Message-ID:
I'm attempting to set up a Boost.Python project outside the Boost.Python tree.
I'm working with a modified version of the jam files provided in
boost\libs\python\example\project.zip (see end of post)
Everything appears to be working perfectly EXCEPT that bjam is attempting to
create a folder whose path is longer than 255 characters long which, on XP,
causes the whole process to fall over with the message "The filename or
extension is too long. "
Other than this one small problem, I believe my configuration works because
I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT
to something shorter than 255 characters and successfully built a useable
'.pyd'.
So. What can I do about these enormous paths? Here is an example:
bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli
ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy
namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre
ading-single
I've googled and found one mention of this problem in 2002, but there was no
resolution or workaround mentioned, simply a comment that it needed to be
fixed.
There's got to be a solution, because I don't run into this problem when I'm
working with the example in the Boost.Python source tree.
Any suggestions very welcome.
Here are the JAM files I'm working with:
------------- Jamrules ---------------------------------------------
path-global BOOST_ROOT : C:/libs/boost ;
PYTHON_ROOT = C:/Python23 ;
PYTHON_VERSION = 2.3 ;
STLPORT_PATH = C:/libs ;
STLPORT_4.5-0725_PATH = C:/libs/STLport-4.5-0725 ;
STLPORT_VERSION = 4.5-0725 ;
TOOLS = msvc-stlport ;
BUILD = release ;
---------- Boost-Build.jam -----------------------------------------
# Specify path to the boost build system
BOOST_ROOT = C:/libs/boost ;
boost-build C:/libs/boost/tools/build ;
---------- Jamfile -----------------------------------------
project-root ;
# Include definitions needed for Python modules
SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
include python.jam ;
# Declare a Python extension called getting_started1
extension getting_started1
: # sources
getting_started1.cpp
: # requirements
# link to the appropriate library for the build variant.
boost_python
boost_python_debug
boost_python_pydebug
# library path required for linking to boost_python shared lib. You
# may need to edit this for your installation
C:/libs/boost/libs/python/build/bin-stage
;
------------------------------------------------------------------
--
Mike
From dave at boost-consulting.com Wed Sep 3 13:23:39 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 03 Sep 2003 07:23:39 -0400
Subject: [C++-sig] Re: Patch to add thread support to invoke function.
References: <001c01c39c31$a36f0b40$0200a8c0@barrack>
<002b01c371b1$3b138170$0200a8c0@barrack>
Message-ID:
"Lijun Qin" writes:
> Hi,
>
> I think a better solution is to give the user choice, I mean use a flag
> which can be passed when calling 'def', such as
> .def('f', f, enableThreadLock)
If you read the links in my previous posting you'll see that I think
that's appropriate for some wrapping jobs; for others (such as
wrapping Qt calls) it seems that calls are so likely to result in a
call back into Python which *must* unconditionally acquire the GIL
that people just want to unblock everywhere.
So far, however, I'm not sure how to do that without incurring ODR
problems, so we may have to go with your idea. Of course, that "flag"
should be rolled into the available functionality of CallPolicies.
> Currently I'm using boost.python to wrap WTL, and it has hundreds of
> functions which are simple SendMessage wrappers, and many of them (I
> think half of them, almost all 'write' operation) can cause callback
> into the python code again, use the notify message such as
> WM_COMMAND, WM_NOTIFY. So write wrapper for every one of them is not
> acceptable. The callback will be implemented use call_method<>
> normally, but the thread acquiring will not be done is call_method,
^^
"in"
> it'll normally be done earlier in the very point the control
> transferred from the 'outside world' to the python extension module,
> in the Windows platform, this will normally at the beginning of COM
> interface method, Window Procedure, or DLL exported function (this
> is rare I think).
When you say "thread acquiring" do you mean the reacquisition of the
Python GIL and thread state? Why would you do it any earlier than in,
or just prior to, call_method<>?
> If we can implement the 'enableThreadLock' flag, but make it a
> 'false' default, it'll be harmless to add this thread support into
> boost.python code, but when needed, it'll be very convenience to
> have them.
I think that's a great approach. Maybe you should extend your prior
CallPolicies patch to do it.
> I do agree that there should be a try catch block here, like:
>
> Py_UNBLOCK_THREADS
> try {
> result = f(...);
> } catch(...)
> Py_BLOCK_THREADS
> throw;
> }
> Py_BLOCK_THREADS
> ...
I wasn't quite suggesting that. First of all Py_UNBLOCK_THREADS needs
a PyThreadState* variable. Secondly, using an object whose destructor
unblocks makes it much easier to select thread blocking or not at
compile time. Something like:
struct thread_enable
{
thread_enable()
: m_thread_state(PyEval_SaveThread())
{}
~thread_enable()
{
PyEval_RestoreThread(m_thread_state);
}
private:
PyThreadState* m_thread_state;
};
We'll just declare one of these on the stack when the thread_enable
flag is used, and declare an unused int when it's not.
A similar, but inverted thread state acquisition object should be
used around call_method<> invocations. My biggest question is: does
it need a thread state, or should it just use PyEval_AcquireLock(),
and if it *does* need a thread state, where will it come from?
> In my case, because SendMessage and COM method will never throw an
> exception, so I ignored them in the last patch, for a complete solution,
> it'll be better to do this.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From RaoulGough at yahoo.co.uk Thu Sep 4 01:02:24 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 04 Sep 2003 00:02:24 +0100
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
Message-ID:
"Joel de Guzman" writes:
> Raoul Gough wrote:
>> "Joel de Guzman" writes:
>
>> Well, I've had a go anyway. I've produced a container_proxy template
>> that wraps a random-access container and provides access via element
>> proxies. The element proxies provide an implicit conversion to the raw
>> value type, and also a constructor from the raw value type, which
>> means that it works with an unchanged[*1] vector_indexing_suite as
>> follows:
>>
>> vector_indexing_suite, true>
>
> This is great! Did the current tests pass with the new code?
[taking a look at libs/python/test] Hey! You've already written some
tests :-) I didn't know about these, but I guess I should have looked
there automatically.
It turns out that the find() functionality needs some additional
comparison operators in the element_proxy. I've added these, and the
vector indexing tests now run without failure. It still requires some
minor tweaks outside of the suite to make it work (i.e.
register_ptr_to_python and implicitly_convertible).
Getting register_ptr_to_python to work seemed a little more difficult
than I would have expected. In particular, the need to specialize
boost::get_pointer probably means making the element_proxy a
non-nested class, since it has to be a deducible type:
template
typename container_proxy::element_proxy::value_type
... get_pointer (container_proxy::element_proxy);
Which I believe doesn't work. I've just provided a non-template
overload for the test cases. I also had to add an "element" typedef to
keep something else happy, and also (at some earlier stage)
iterator_category and difference_type. This all reinforces my thoughts
from a few weeks back, about the need for some kind of centralized
handle_traits or proxy_traits.
[snip]
>> Sample output:
>>
>> copy is 3, v[1] is 3
>> copy is 5, v[1] is 5 # Wrong - copy should remain unchanged
>>
>> The container_proxy wrapper fixes that problem (whatever it is,
>> probably minor) but doesn't fix the following additional problem, that
>> both versions exhibit:
>
> Indeed. It's nice to hear that container_proxy fixed this.
>
>> slice = v[1:2]
>> print "slice[0] is %s, v[1] is %s" % (slice[0], v[1])
>>
>> v[1].increment()
>> print "slice[0] is %s, v[1] is %s" % (slice[0], v[1])
>>
>> Sample output:
>>
>> slice[0] is 5, v[1] is 5
>> slice[0] is 5, v[1] is 6 # Should be slice[0] is 6, v[1] is 6
>>
>> This may be a fundamental problem with how slices are returned.
>> Compiler is gcc 3.3.1 (mingw special 20030804-1).
>
> Right. slices are currently returned by value. I guess this is another
> area to be explored. I think I know how to deal with it. Let's do
> it when we refactor the slicing stuff. I think this is a good start. There
> are lots of things to do and I certainly am glad that you can help. I've
> already been bitten by the wholesale approach of the current indexing
> suites (more on that later) that I really need to break it up sometime
> soon!
I've also been thinking about the slice return value problem, and I
believe the best answer is to return a real Python list containing
element proxies. My reasoning is that we can't return a container of
identical type to the original, since it has value semantics and we
need reference semantics to be at all Python-like. Unfortunately, this
means that the following won't work:
# Given wrapped C++ function foo (std::vector const &)
foo (v) # OK - called on std::vector
foo (v[1:4]) # !OK - called on Python list
Then again, it also wouldn't work if v[1:4] was a wrapped
vector, so why not just use a real Python list and save
some template instantiation work. Actually, I'm not sure whether
creating a working vector wrapper might not mean more
programming work for us as well, in which case I'm definitely against
it :-)
My latest code is available from the boost-sandbox CVS in the
boost-sandbox/boost/python/suite/indexing directory. Note: could it be
that the anonymous server is out of date with the SSH one? I could
only retrieve the stuff I added via the
:ext:raoulgough at cvs.boost-sandbox... path.
--
Raoul Gough.
(setq dabbrev-case-fold-search nil)
From dave at boost-consulting.com Wed Sep 3 14:54:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 03 Sep 2003 08:54:21 -0400
Subject: [C++-sig] Re: undefined symbol "typeinfo for
boost::python::instance_holder " under Linux/RH9
In-Reply-To: <26E3EC48949D134C94A1574B2C89466117546D@exchange2.slac.stanford.edu>
(Matthew
David Langston's message of "Sat, 30 Aug 2003 17:59:17 -0700")
References: <26E3EC48949D134C94A1574B2C89466117546D@exchange2.slac.stanford.edu>
Message-ID:
"Langston, Matthew David" writes:
> Hi Dave,
>
> Under Linux I simply did a bjam "-sTOOLS=gcc", which created
>
> boost/libs/python/build/bin-stage/libboost_python.a
>
> which bjam appears to have copied (based on file sizes) from
>
> boost/libs/python/build/bin/libboost_python.a/gcc/release/runtime-link-dynamic/libboost_python.a
>
> So, I assume bjam built everything properly. What else to try? Are you
> saying that statically linking to libboost_python.a on linux/gcc
> should work?
Yes, it should work.
> I am using boost 1.30.0, so would upgrading to 1.30.2
> maybe help?
Yes, perhaps, though your problem has the flavor of a compiler/linker bug.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From dave at boost-consulting.com Wed Sep 3 15:01:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 03 Sep 2003 09:01:48 -0400
Subject: [C++-sig] Re: Cross module definition
References:
Message-ID:
"Arnaud PICARD" writes:
> Sorry, my latest mail was sent before I'd had time to complete it...
> --------------------------
>
> Hello,
>
> As I've already mentionned, I still have problems with cross def.
> Here you'll find an example I've used to test a method. I'm not sure I've
> done it right (actually I guess it's false since I can't get it to work
> properly)
>
> So, in these modules, I have define one as ModuleA and the other as
> ModuleB.
> They are AFAIK well written.
>
> If I import them under python, and define a = ModuleA.Cmplx( 1., 0. ), b =
> ModuleB.Printer(), and then try b.print1( a ) or b.print2( a ) it won't
> work.
> If I define a with ModuleB instead of ModuleA it's running. That's still
> the same problem I had with cross-module definition, with an example... If
> I remove the line define_Cmplx() from ModuleD definition, I still cannot
> get it to work even though I've imported first ModuleA then ModuleB.
>
> What do I have to do so that I can pull the line "define_Cmplx()" out of my
> ModuleB definition so that ModuleB's methods recognize my class Cmplx ?
> I've understood what was reponsded last time, but I have not been able to
> have it work properly...
Well, a real complete example that actually compiles on a conforming
C++ compiler and includes the precise Python code to execute would be
a big help in being sure that I was reproducing your case precisely,
but after massageing your code so it would compile (changed
to , added "using namespace std;", removed
define_Cmplx() from ModuleB) I get:
1 + 0 i
1 + 0 i
For both b.print1(a) and b.print2(a). On my compilers.
Which compiler and platform are you using?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From dave at boost-consulting.com Wed Sep 3 14:54:07 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 03 Sep 2003 08:54:07 -0400
Subject: [C++-sig] Re: undefined symbol "typeinfo for
boost::python::instance_holder " under Linux/RH9
References: <26E3EC48949D134C94A1574B2C89466117546D@exchange2.slac.stanford.edu>
Message-ID:
"Langston, Matthew David" writes:
> Hi Dave,
>
> Under Linux I simply did a bjam "-sTOOLS=gcc", which created
>
> boost/libs/python/build/bin-stage/libboost_python.a
>
> which bjam appears to have copied (based on file sizes) from
>
> boost/libs/python/build/bin/libboost_python.a/gcc/release/runtime-link-dynamic/libboost_python.a
>
> So, I assume bjam built everything properly. What else to try? Are you
> saying that statically linking to libboost_python.a on linux/gcc
> should work?
Yes, it should work.
> I am using boost 1.30.0, so would upgrading to 1.30.2
> maybe help?
Yes, perhaps, though your problem has the flavor of a compiler/linker bug.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From rwgk at yahoo.com Wed Sep 3 20:47:27 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 3 Sep 2003 11:47:27 -0700 (PDT)
Subject: [C++-sig] Cross module definition
In-Reply-To:
Message-ID: <20030903184727.8334.qmail@web20205.mail.yahoo.com>
--- Arnaud PICARD wrote:
> If I import them under python, and define a = ModuleA.Cmplx( 1., 0. ), b =
> ModuleB.Printer(), and then try b.print1( a ) or b.print2( a ) it won't
> work.
It works here without a problem. The only change I made is to remove
define_Cmplx(); from Boost_B.cc. Any problems you have must be related
to how you compile and link. Here is how I did it under Redhat 8.0:
g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/dist/boost
-I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_A.os
/net/cci/rwgk/dist/sandbx/cross_module_problem/Boost_A.cc
g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/dist/boost
-I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_B.os
/net/cci/rwgk/dist/sandbx/cross_module_problem/Boost_B.cc
g++ -shared -o libtbx/sandbx_boost/ModuleB.so
sandbx/cross_module_problem/Boost_B.os -Llibtbx -lboost_python -lm
g++ -shared -o libtbx/sandbx_boost/ModuleA.so
sandbx/cross_module_problem/Boost_A.os -Llibtbx -lboost_python -lm
% cat tst.py
from sandbx_boost import ModuleA
from sandbx_boost import ModuleB
a = ModuleA.Cmplx( 1., 0. )
b = ModuleB.Printer()
b.print1( a )
b.print2( a )
% python tst.py
1 + 0 i
1 + 0 i
Ralf
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From rwgk at yahoo.com Thu Sep 4 19:08:02 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 4 Sep 2003 10:08:02 -0700 (PDT)
Subject: [C++-sig] Cross module definition
In-Reply-To:
Message-ID: <20030904170802.13048.qmail@web20201.mail.yahoo.com>
This is my second attempt at replying to your message. Something
seems to be wrong with the mailing list...
Now trying to remember what I wrote:
--- Arnaud PICARD wrote:
> What do I have to do so that I can pull the line "define_Cmplx()" out of my
> ModuleB definition so that ModuleB's methods recognize my class Cmplx ?
> I've understood what was reponsded last time, but I have not been able to
> have it work properly...
It works perfectly here under Redhat 8.0. The only change I made to your
sources is to remove the define_Cmplx(); line from Boost_B.cc. I think
your problems must be due to how you compile and link. This is what
I did:
g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/hot/boost
-I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_A.os
/net/cci/rwgk/hot/sandbx/cross_module_problem/Boost_A.cc
g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -I/net/cci/rwgk/hot/boost
-I/usr/include/python2.2 -c -o sandbx/cross_module_problem/Boost_B.os
/net/cci/rwgk/hot/sandbx/cross_module_problem/Boost_B.cc
g++ -shared -o libtbx/sandbx_boost/ModuleB.so
sandbx/cross_module_problem/Boost_B.os -Llibtbx -lboost_python -lm
g++ -shared -o libtbx/sandbx_boost/ModuleA.so
sandbx/cross_module_problem/Boost_A.os -Llibtbx -lboost_python -lm
% cat tst.py
from sandbx_boost import ModuleA
from sandbx_boost import ModuleB
a = ModuleA.Cmplx( 1., 0. )
b = ModuleB.Printer()
b.print1( a )
b.print2( a )
% python tst.py
1 + 0 i
1 + 0 i
Ralf
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From mike.thompson at day8.com.au Thu Sep 4 23:44:52 2003
From: mike.thompson at day8.com.au (Mike Thompson)
Date: Fri, 5 Sep 2003 07:44:52 +1000
Subject: [C++-sig] "The filename or extension is too long"
Message-ID:
I'm attempting to set up a Boost.Python project outside the Boost.Python tree.
I'm working with a modified version of the jam files provided in
boost\libs\python\example\project.zip (see end of post)
Everything appears to be working perfectly EXCEPT that bjam is attempting to
create a folder whose path is longer than 255 characters long which, on XP,
causes the whole process to fall over with the message "The filename or
extension is too long. "
Other than this one small problem, I believe my configuration works because
I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT
to something shorter than 255 characters and successfully built a useable
'.pyd'.
So. What can I do about these enormous paths? Here is an example:
bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli
ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy
namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre
ading-single
I've googled and found one mention of this problem in 2002, but there was no
resolution or workaround mentioned, simply a comment that it needed to be
fixed.
There's got to be a solution, because I don't run into this problem when I'm
working with the example in the Boost.Python source tree.
Any suggestions very welcome.
Here are the bjam files I'm working with:
------------- Jamrules ---------------------------------------------
path-global BOOST_ROOT : C:/libs/boost ;
PYTHON_ROOT = C:/Python23 ;
PYTHON_VERSION = 2.3 ;
STLPORT_PATH = C:/libs ;
STLPORT_4.5-0725_PATH = C:/libs/STLport-4.5-0725 ;
STLPORT_VERSION = 4.5-0725 ;
TOOLS = msvc-stlport ;
BUILD = release ;
---------- Boost-Build.jam -----------------------------------------
# Specify path to the boost build system
BOOST_ROOT = C:/libs/boost ;
boost-build C:/libs/boost/tools/build ;
---------- Jamfile -----------------------------------------
project-root ;
# Include definitions needed for Python modules
SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
include python.jam ;
# Declare a Python extension called getting_started1
extension getting_started1
: # sources
getting_started1.cpp
: # requirements
# link to the appropriate library for the build variant.
boost_python
boost_python_debug
boost_python_pydebug
# library path required for linking to boost_python shared lib. You
# may need to edit this for your installation
C:/libs/boost/libs/python/build/bin-stage
;
------------------------------------------------------------------
--
Mike
From dave at boost-consulting.com Fri Sep 5 02:08:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 04 Sep 2003 20:08:21 -0400
Subject: [C++-sig] Re: "The filename or extension is too long"
References:
Message-ID:
"Mike Thompson" writes:
> I'm attempting to set up a Boost.Python project outside the Boost.Python tree.
> I'm working with a modified version of the jam files provided in
> boost\libs\python\example\project.zip (see end of post)
>
> Everything appears to be working perfectly EXCEPT that bjam is attempting to
> create a folder whose path is longer than 255 characters long which, on XP,
> causes the whole process to fall over with the message "The filename or
> extension is too long. "
>
> Other than this one small problem, I believe my configuration works because
> I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT
> to something shorter than 255 characters and successfully built a useable
> '.pyd'.
>
> So. What can I do about these enormous paths? Here is an example:
>
> bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli
> ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy
> namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre
> ading-single
>
> I've googled and found one mention of this problem in 2002, but there was no
> resolution or workaround mentioned, simply a comment that it needed to be
> fixed.
I don't know, man. Something's seriously wrong that all of these
properties which already match their default values are showing up in
the subvariant path. Rene, can I impose upon you to look into this?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nicodemus at globalite.com.br Fri Sep 5 00:47:29 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 04 Sep 2003 19:47:29 -0300
Subject: [C++-sig] Pyste code generation.
In-Reply-To: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B10@exchange.adrembi.com>
References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B10@exchange.adrembi.com>
Message-ID: <3F57C101.5010806@globalite.com.br>
Roman Yakovenko wrote:
> Hi Nicodemus. Today Pyste does not generate private virtual functions, right?
>( in wrapper class of class that has private pure virtual )
>May be it should be changed? Why ? I write wrapper for library that uses template
>method pattern, where customization of method done by virtual private functions.
>Here is the full artical http://www.gotw.ca/publications/mill18.htm.
>
>
Hi Roman,
I just commited a change that allows you to override protected and
private pure virtual functions in Python. Sorry about the delay and
thanks for the feedback!
Regards,
Nicodemus.
From qinlj at solidshare.com Fri Sep 5 02:33:20 2003
From: qinlj at solidshare.com (Lijun Qin)
Date: Fri, 5 Sep 2003 08:33:20 +0800
Subject: [C++-sig] Re: Patch to add thread support to invoke function.
References: <001c01c39c31$a36f0b40$0200a8c0@barrack><002b01c371b1$3b138170$0200a8c0@barrack>
Message-ID: <006401c37345$540afdd0$0200a8c0@barrack>
> > it'll normally be done earlier in the very point the control
> > transferred from the 'outside world' to the python extension module,
> > in the Windows platform, this will normally at the beginning of COM
> > interface method, Window Procedure, or DLL exported function (this
> > is rare I think).
>
> When you say "thread acquiring" do you mean the reacquisition of the
> Python GIL and thread state? Why would you do it any earlier than in,
> or just prior to, call_method<>?
>
This is because before the call_method<>, we'll normally 'touch' some python
object, so acquiring the Python GIL is needed.
Of couse, this is not always the case, but since this is common, so I think
do acquiring ealier is safter.
> A similar, but inverted thread state acquisition object should be
> used around call_method<> invocations. My biggest question is: does
> it need a thread state, or should it just use PyEval_AcquireLock(),
> and if it *does* need a thread state, where will it come from?
>
According to the python document and my experiences, before a thread call
Python core, it must allocate a thread state,
If this is the main thread where Py_Initialize() is called, it's just:
PyThreadState* s_thisThread = PyThreadState_Swap(NULL);
After s_thisThread is valid, one must acquire the GIL to use the interceptor
_ASSERT(s_thisThread);
PyEval_AcquireThread(s_thisThread);
...
call other Python API
..
PyEval_ReleaseThread(s_thisThread);
In the 'invoke' case, PyEval_SaveThread/PyEval_RestoreThread is sufficient,
but in the 'call_method<>' case, one must ensure a thread state is valid,
currently, I use PyWinThreadState_Ensure() come from pywintypes.dll, which
used 'thread local storage' to save the PyThreadState*.
I'm not familiar with Unix platform, so I do not known whether it can be
used in unix platform.
Lijun Qin
http://www.solidshare.com
From jjanecek at telusplanet.net Fri Sep 5 08:19:52 2003
From: jjanecek at telusplanet.net (John Janecek)
Date: Fri, 05 Sep 2003 00:19:52 -0600
Subject: [C++-sig] Creating an arbitrary sized boost string ?
In-Reply-To:
Message-ID: <5.1.0.14.2.20030905001157.00b63078@pop.telusplanet.net>
I can create a string using
str(char* data)
where data is a null terminated string
what about if data is not a null terminated string ?
like i need something like
str(unsigned char* data, datalen)
how can i do this ?
Thanx, it is probably in the docs but i can not find it :(
so please do not flame me too bad :)
From jacek.generowicz at cern.ch Fri Sep 5 17:25:20 2003
From: jacek.generowicz at cern.ch (Jacek Generowicz)
Date: Fri, 05 Sep 2003 15:25:20 -0000
Subject: [C++-sig] Boost: virtual inheritance
Message-ID:
Here's the distillation of some classes we are trying to wrap with
Boost.Python, and the way we are trying to do the wrapping.
===========================================================
#include
struct Item {
std::string name();
};
std::string Item::name() {
return std::string("hello");
}
class Class : virtual public Item {
int foo();
};
int Class::foo() {
return 42;
}
#include
using namespace boost::python;
BOOST_PYTHON_MODULE( btry ) {
class_- ("Item", no_init);
class_ >("Class") //, no_init)
.def("name", &Class::name);
===========================================================
It looks as if the virtual inheritance of Item is what is causing the
trouble. It appears as if the following is the relevant part of the
compilation error messsage:
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer
to member conversion via virtual base `Item' of `Class'
Making the inheritance non-virtual makes the distilled example, at
least, work fine.
Any hints would be warmly appreciated.
For completeness (and your enjoyment), we include the full error message ...
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/ -I../../../../Dictionary/Reflection -I/afs/cern.ch/sw/lcg/external/Python/2.2.2/rh73_gcc32/include/python2.2 -c boosttry.cpp -o build/temp.linux-i686-2.2/boosttry.o -g
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp: In
member function `void boost::python::class_::def_impl(const
char*, Fn, const Helper&, ...) [with Fn = std::string (Item::*)(), Helper =
boost::python::detail::def_helper, T = Class, X1 =
boost::python::bases
- , X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]':
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:246: instantiated from `boost::python::class_& boost::python::class_::def(const char*, F) [with F = std::string (Item::*)(), T = Class, X1 = boost::python::bases
- , X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
boosttry.cpp:33: instantiated from here
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer
to member conversion via virtual base `Item' of `Class'
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/inheritance.hpp: In
static member function `static boost::python::objects::dynamic_id_t
boost::python::objects::polymorphic_id_generator::execute(void*) [with T
= Class]':
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/inheritance.hpp:78: instantiated from `void boost::python::objects::register_dynamic_id(T*) [with T = Class]'
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/class_converters.hpp:77: instantiated from `void boost::python::objects::register_class_from_python(Derived*, Bases*) [with Derived = Class, Bases = boost::python::bases
- ]'
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:476: instantiated from `void boost::python::class_::register_() const [with T = Class, X1 = boost::python::bases
- , X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:494: instantiated from `boost::python::class_::class_(const char*, const char*) [with T = Class, X1 = boost::python::bases
- , X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
boosttry.cpp:29: instantiated from here
/afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/object/inheritance.hpp:48: cannot
dynamic_cast `p' (of type `class Class*') to type `void*' (source type is
not polymorphic)
error: command 'gcc' failed with exit status 1
From dave at boost-consulting.com Fri Sep 5 22:32:57 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 05 Sep 2003 16:32:57 -0400
Subject: [C++-sig] Re: Creating an arbitrary sized boost string ?
References:
<5.1.0.14.2.20030905001157.00b63078@pop.telusplanet.net>
Message-ID:
John Janecek writes:
> I can create a string using
>
> str(char* data)
> where data is a null terminated string
>
> what about if data is not a null terminated string ?
>
> like i need something like
> str(unsigned char* data, datalen)
>
> how can i do this ?
Probably the easiest way is with:
str(std::string(data, data+datalen))
I agree that it would be nice to have the constructor you're asking
for, but it would be a departure from the Python interface; is it a
good idea? It might be...
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From dave at boost-consulting.com Fri Sep 5 22:56:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 05 Sep 2003 16:56:48 -0400
Subject: [C++-sig] Re: "The filename or extension is too long"
References:
Message-ID:
David Abrahams writes:
> "Mike Thompson" writes:
>
>> I'm attempting to set up a Boost.Python project outside the Boost.Python tree.
>> I'm working with a modified version of the jam files provided in
>> boost\libs\python\example\project.zip (see end of post)
>>
>> Everything appears to be working perfectly EXCEPT that bjam is attempting to
>> create a folder whose path is longer than 255 characters long which, on XP,
>> causes the whole process to fall over with the message "The filename or
>> extension is too long. "
>>
>> Other than this one small problem, I believe my configuration works because
>> I've done "bjam -n -oBUILD.BAT" , hand-modified the folder names in BUILD.BAT
>> to something shorter than 255 characters and successfully built a useable
>> '.pyd'.
>>
>> So. What can I do about these enormous paths? Here is an example:
>>
>> bin\getting_started1.pyd\msvc-stlport\release\debug-symbols-on\exception-handli
>> ng-on\inlining-off\optimization-off\rtti-on\runtime-build-debug\runtime-link-dy
>> namic\stlport-cstd-namespace-std\stlport-iostream-on\stlport-version-4.5.3\thre
>> ading-single
>>
>> I've googled and found one mention of this problem in 2002, but there was no
>> resolution or workaround mentioned, simply a comment that it needed to be
>> fixed.
>
> I don't know, man. Something's seriously wrong that all of these
> properties which already match their default values are showing up in
> the subvariant path. Rene, can I impose upon you to look into this?
Mike,
Try the enclosed patch and let me know if it works out
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boost-base.patch
Type: text/x-patch
Size: 1924 bytes
Desc: not available
URL:
-------------- next part --------------
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From djowel at gmx.co.uk Sat Sep 6 03:32:58 2003
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Sat, 6 Sep 2003 09:32:58 +0800
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
Message-ID: <00f101c37416$d520e070$64646464@godzilla>
Hi Raoul,
I've spent some time and perused your code. Nice!
Although our discussion has been rather sketchy at best,
I think I like the general direction this is leading to. Please
don't let me slow you down. You've done a nice work.
Keep it coming :-) !
Raoul Gough wrote:
> "Joel de Guzman" writes:
>
>> Raoul Gough wrote:
>>> "Joel de Guzman" writes:
>>
>>> Well, I've had a go anyway. I've produced a container_proxy template
>>> that wraps a random-access container and provides access via element
>>> proxies. The element proxies provide an implicit conversion to the raw
>>> value type, and also a constructor from the raw value type, which
>>> means that it works with an unchanged[*1] vector_indexing_suite as
>>> follows:
>>>
>>> vector_indexing_suite, true>
>>
>> This is great! Did the current tests pass with the new code?
>
> [taking a look at libs/python/test] Hey! You've already written some
> tests :-) I didn't know about these, but I guess I should have looked
> there automatically.
>
> It turns out that the find() functionality needs some additional
> comparison operators in the element_proxy. I've added these, and the
> vector indexing tests now run without failure. It still requires some
> minor tweaks outside of the suite to make it work (i.e.
> register_ptr_to_python and implicitly_convertible).
I just had a problem with the find() functionality. The problem is that it
assumes that the element type of the container to be wraped has ==.
This is not always the case. Yet, I am not sure how to detect
that at compile time and disable the feature appropriately. I think a
basic problem with an all-in-one suite is that the requirements become
too broad. We really should break the thing down in smaller, easy to
manage pieces.
>> Right. slices are currently returned by value. I guess this is another
>> area to be explored. I think I know how to deal with it. Let's do
>> it when we refactor the slicing stuff. I think this is a good start. There
>> are lots of things to do and I certainly am glad that you can help. I've
>> already been bitten by the wholesale approach of the current indexing
>> suites (more on that later) that I really need to break it up sometime
>> soon!
>
> I've also been thinking about the slice return value problem, and I
> believe the best answer is to return a real Python list containing
> element proxies. My reasoning is that we can't return a container of
> identical type to the original, since it has value semantics and we
> need reference semantics to be at all Python-like. Unfortunately, this
> means that the following won't work:
>
> # Given wrapped C++ function foo (std::vector const &)
>
> foo (v) # OK - called on std::vector
> foo (v[1:4]) # !OK - called on Python list
>
> Then again, it also wouldn't work if v[1:4] was a wrapped
> vector, so why not just use a real Python list and save
> some template instantiation work. Actually, I'm not sure whether
> creating a working vector wrapper might not mean more
> programming work for us as well, in which case I'm definitely against
> it :-)
I am considering a slice_proxy. I am not sure how complicated
the implementation will be, but I think this is the right solution to the problem.
Schematically:
slice_proxy
{
Container& c;
Index from;
Index to;
};
As for the foo (v[1:4]) problem, you can have an implicit conversion from
a slice_proxy to a Container.
Thoughts?
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
From dave at boost-consulting.com Sat Sep 6 05:29:51 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 05 Sep 2003 23:29:51 -0400
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
<00f101c37416$d520e070$64646464@godzilla>
Message-ID:
"Joel de Guzman" writes:
>> Then again, it also wouldn't work if v[1:4] was a wrapped
>> vector, so why not just use a real Python list and save
>> some template instantiation work. Actually, I'm not sure whether
>> creating a working vector wrapper might not mean more
>> programming work for us as well, in which case I'm definitely against
>> it :-)
>
> I am considering a slice_proxy. I am not sure how complicated
> the implementation will be, but I think this is the right solution to the problem.
> Schematically:
>
> slice_proxy
> {
> Container& c;
> Index from;
> Index to;
> };
>
> As for the foo (v[1:4]) problem, you can have an implicit conversion from
> a slice_proxy to a Container.
Consider whether this might be a way to save on template
instantiations:
slice_proxy
{
object c;
object from;
object to;
};
Remember, the container is already wrapped into a runtime-polymorphic
object ;-)
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From dave at boost-consulting.com Sat Sep 6 10:35:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 06 Sep 2003 04:35:21 -0400
Subject: [C++-sig] Re: Boost: virtual inheritance
References:
Message-ID:
Jacek Generowicz writes:
> Here's the distillation of some classes we are trying to wrap with
> Boost.Python, and the way we are trying to do the wrapping.
>
> ===========================================================
> #include
>
> struct Item {
> std::string name();
> };
>
> std::string Item::name() {
> return std::string("hello");
> }
>
>
> class Class : virtual public Item {
> int foo();
> };
>
> int Class::foo() {
> return 42;
> }
>
>
> #include
> using namespace boost::python;
>
> BOOST_PYTHON_MODULE( btry ) {
>
> class_
- ("Item", no_init);
>
> class_ >("Class") //, no_init)
> .def("name", &Class::name);
> ===========================================================
>
>
> It looks as if the virtual inheritance of Item is what is causing the
> trouble. It appears as if the following is the relevant part of the
> compilation error messsage:
>
> /afs/cern.ch/sw/lcg/external/Boost/1.30.2/rh73_gcc32/boost/python/class.hpp:395: pointer
> to member conversion via virtual base `Item' of `Class'
>
> Making the inheritance non-virtual makes the distilled example, at
> least, work fine.
>
> Any hints would be warmly appreciated.
The quick workaround is:
.def("name", object(&Class::name))
HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From RaoulGough at yahoo.co.uk Sat Sep 6 11:24:09 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sat, 06 Sep 2003 10:24:09 +0100
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
<00f101c37416$d520e070$64646464@godzilla>
Message-ID:
David Abrahams writes:
> "Joel de Guzman" writes:
>
>>> Then again, it also wouldn't work if v[1:4] was a wrapped
>>> vector, so why not just use a real Python list and
>>> save some template instantiation work. Actually, I'm not sure
>>> whether creating a working vector wrapper might not
>>> mean more programming work for us as well, in which case I'm
>>> definitely against it :-)
>>
>> I am considering a slice_proxy. I am not sure how
>> complicated the implementation will be, but I think this is the
>> right solution to the problem. Schematically:
>>
>> slice_proxy
>> {
>> Container& c;
>> Index from;
>> Index to;
>> };
>>
>> As for the foo (v[1:4]) problem, you can have an implicit
>> conversion from a slice_proxy to a Container.
>
> Consider whether this might be a way to save on template
> instantiations:
>
> slice_proxy
> {
> object c;
> object from;
> object to;
> };
>
> Remember, the container is already wrapped into a runtime-polymorphic
> object ;-)
I already considered and had to reject an approach like this.
Actually, I was thinking of using an iterator pair, but the problem
would be the same. A slice on this basis will be in error as soon as
an insertion or deletion occurs within the [from,to) range in the
original container, since the value lookup is deferred until elements
are accessed in the slice. To function correctly, the slice must
contain proxies for each element in the range _at the time the slice
was created_, so the proxies can track their values' movements during
inserts, erasures and overwrites. I currently like the idea of
returning a Python list of element proxies, since it saves code and
template instantiations.
Possibly a wrapped std::vector with a suite
specialization would be better than a Python list, but I'm not sure
exactly what the pros and cons would be.
--
Raoul Gough.
(setq dabbrev-case-fold-search nil)
From RaoulGough at yahoo.co.uk Sat Sep 6 11:43:25 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Sat, 06 Sep 2003 10:43:25 +0100
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
<00f101c37416$d520e070$64646464@godzilla>
Message-ID:
"Joel de Guzman" writes:
> Hi Raoul,
>
> I've spent some time and perused your code. Nice!
> Although our discussion has been rather sketchy at best,
> I think I like the general direction this is leading to. Please
> don't let me slow you down. You've done a nice work.
> Keep it coming :-) !
Thanks! I should have some more time for this in the next few days, so
I'll see what I can do.
>
> Raoul Gough wrote:
[snip]
>> It turns out that the find() functionality needs some additional
>> comparison operators in the element_proxy. I've added these, and the
>> vector indexing tests now run without failure. It still requires some
>> minor tweaks outside of the suite to make it work (i.e.
>> register_ptr_to_python and implicitly_convertible).
>
> I just had a problem with the find() functionality. The problem is that it
> assumes that the element type of the container to be wraped has ==.
> This is not always the case. Yet, I am not sure how to detect
> that at compile time and disable the feature appropriately. I think a
> basic problem with an all-in-one suite is that the requirements become
> too broad. We really should break the thing down in smaller, easy to
> manage pieces.
I see. Unless there is some kind of template meta-programming magic to
detect operator==, we would need a manual switch. Maybe we could break
this down by introducing not only a container_traits template, but a
value_traits one as well. The container_traits could then make use of
value_traits internally to figure out whether
things like find() are possible, and the client code could specialize
value_traits where necessary. In most cases, of course, the defaults
would work, but in special cases only minimal work is required for the
client code, since value_traits would probably be very simple.
I guess the next thing to do is pull some of the existing work
together, maybe adding the new value_traits template and a partial
specialization of container_traits for container_proxy. I'll try to
make some progress on this before the middle of the week.
One thing we haven't yet considered is support for different
conversion policies. Hopefully I'm not just being overly optimistic,
and we can retro-fit this later.
[snip slice discussion - see my reply to Dave's followup]
--
Raoul Gough.
(setq dabbrev-case-fold-search nil)
From djowel at gmx.co.uk Sat Sep 6 15:56:21 2003
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Sat, 6 Sep 2003 21:56:21 +0800
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
<00f101c37416$d520e070$64646464@godzilla>
Message-ID: <002701c3747e$df934da0$64646464@godzilla>
Raoul Gough wrote:
> David Abrahams writes:
>> Consider whether this might be a way to save on template
>> instantiations:
>>
>> slice_proxy
>> {
>> object c;
>> object from;
>> object to;
>> };
>>
>> Remember, the container is already wrapped into a runtime-polymorphic
>> object ;-)
>
> I already considered and had to reject an approach like this.
> Actually, I was thinking of using an iterator pair, but the problem
> would be the same. A slice on this basis will be in error as soon as
> an insertion or deletion occurs within the [from,to) range in the
> original container, since the value lookup is deferred until elements
No, of course not. slice_proxy shouldn't be that naive.
The slice_proxy can be thought of as:
slice_proxy
{
element_proxy from;
element_proxy to;
};
The same element_proxy index management should apply to from and to.
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
From dave at boost-consulting.com Sat Sep 6 15:57:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 06 Sep 2003 09:57:00 -0400
Subject: [C++-sig] Re: Adding __len__ to range objects
References:
<021801c3659d$5190a290$64646464@godzilla>
<003d01c36682$5ec55c40$0100a8c0@godzilla>
<00d101c36adb$0087aea0$64646464@godzilla>
<004a01c36b0c$cf71b0e0$50a245ca@godzilla>
<00de01c371b4$51acd8c0$64646464@godzilla>
<00f101c37416$d520e070$64646464@godzilla>
Message-ID:
Raoul Gough writes:
>
> I see. Unless there is some kind of template meta-programming magic to
> detect operator==, we would need a manual switch. Maybe we could break
> this down by introducing not only a container_traits template, but a
> value_traits one as well. The container_traits could then make use of
> value_traits internally to figure out whether
> things like find() are possible, and the client code could specialize
> value_traits where necessary. In most cases, of course, the defaults
> would work, but in special cases only minimal work is required for the
> client code, since value_traits would probably be very simple.
Yup. This is all starting to sound a lot like Alexander Nasonov's
dynamic_any.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From djowel at gmx.co.uk Sat Sep 6 17:06:26 2003
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Sat, 6 Sep 2003 23:06:26 +0800
Subject: [C++-sig] Re: Adding __len__ to range objects
References: