Mailman 3 May 2000 - Cplusplus-sig

Announcing CXX 5.0
by Barry Scott May 29, 2000

May 29, 2000

CXX 5.0 is tagged on SourceForge with the name "CXX_5_0". The older version 4.2 source did not contain all the work done on CXX before creation on SourceForge. 5.0 contains all the work that has been done on CXX. We will now start working towards CXX 5.1. The main work items I know about are: * Use Geoffrey Furnish's Invoke method. This method solves the problem of mixing C++ and C pointers * Merge David Abraham's simplified object wrapping * Analysis and merge the code from the patches no SourceForge * Fix bugs as reported * Improve usability * Ensure CXX is written in ANSI C++ as far as is practical given the state of available C++ compilers. BArry

1 0

Re: [C++-SIG] Submitting candidate changes to CXX
by Steve Harris May 28, 2000

May 28, 2000

"Paul F. Dubois" <dubois1(a)llnl.gov> writes: [...] > Can you explain your last point? You mean I had a memory leak? > > At least one of them is on purpose: when you initialize the module > you have to make sure that the Module object has an infinite > lifetime. There are a few static methods that take the same basic shape, such as Py::ExtensionModule::methods(). In the CVS version, it keeps a static pointer which is initially null. In each call, it checks to see if the pointer is still null. If so, it heap allocates a method_map_t variable and returns that variable by reference. But how and when would that pointer ever get deleted? My candidate replacement takes this form: static method_map_t &methods(void) { static method_map_t map_of_methods; return map_of_methods; } Since map_of_methods is a static local variable, it's guaranteed to be cleaned up eventually. We know that an exiting process will likely clean up most heap-allocated memory, but the above form seems more trustworthy unless you're deliberately trying to control _when_ the variable gets deleted. > It shouldn't be necessary to eliminate temporaries; any good > compiler will do this. There are some in the tests that look like > temporaries but in fact are doing Python-type checking and for > debugging purposes I did things in steps. Okay. Perhaps you can then veto some of the changes. Maybe it's just a style thing. I always think of Scott Meyers' "Item" on named temporary variables: the compiler can't take as much liberty in eliminating them. I'll let you be the judge. > Thanks for helping us. No problem. It's harder to jump in when you can't just talk about a change in the hallway. Please let me know when I'm stepping on any assumptions or procedures so I can stop. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

2 1

Re: [C++-SIG] Problems building and testing CXX demo
by Steve Harris May 24, 2000

May 24, 2000

Phil Austin <phil(a)geog.ubc.ca> writes: > Out of curiosity, are you still having to live with 30 minute compile > times, or did you find a way to speed things up? No, we're down to about four minutes in the worst case. I think the problem was mixing g++/gcc with Sun's native assembler and linker. Once we rebuilt g++ to use the Gnu binutils, everything got faster. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

1 0

Problems building and testing CXX demo
by Steve Harris May 23, 2000

May 23, 2000

[g++ 2.95.2 on solaris 2.5.1] I'm trying to build the latest CXX demonstration module 'example' and run its test suite. Seeing that CXX ships with a 'setup.py' file, I used Distutils to build and install the module. I was also careful to follow the Readme file's warnings about first building Python with the LINKCC and LDSHARED environmental variables set. Python built fine, and the 'example' module builds fine - though it takes about 30 minutes to build! Once I install the built 'example' module, I can fire up the python interpreter and type >>> from example import * ... (an 'r' gets created and destroyed) >>> test() At that point, python aborts and dumps core. The stack trace looks like a thrown exception is leaking out and aborting the program. Has anyone else noticed this problem? I can provide a stack trace if necessary. Can anyone provide some advice on how to build the 'python.cxx' sample interpreter that's supposed to link with the 'example' module? I've tried to work through adding this module to a 'Setup.in' file and going through the 'Makefile.pre.in' steps to build an embedded interpreter, but that all seems like overkill for such a deceptively simple task. Any input would be appreciated. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

3 3

Submitting candidate changes to CXX
by Steve Harris May 23, 2000

May 23, 2000

I started working a CVS checkout of CXX today and found some nits that I'd like to fix. I've changed the code here, but I don't have write access to the CVS tree (and nor should I). What is the process for getting candidate changes reviewed, approved, and submitted? The nature of my changes are: * Tighten const-correctness where possible * Reduce repetitive lookups into std::map * Eliminate some (explicit named) temporary variables * Eliminate heap-allocated static variables (that won't get cleaned up) Please advise. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

2 1

Re: [C++-SIG] How to use CXX...
by Steve Harris May 23, 2000

May 23, 2000

"Paul F. Dubois" <dubois1(a)llnl.gov> writes: > It is clear that a Python sequence type is a random access container. The > class Sequence in CXX is too. If you want to wrap a class that is not a > random access container, then it isn't a Sequence. You can invent a new > class for it that is a child of Object in the same way that Sequence is, > with whatever access rules you think are appropriate, but if your can't do > x[i] in reasonable time it is simply deceptive to have such an operator. The syntax I'm looking to enable is just iteration: for item in seq print item >From looking at the CXX Sequence implementation, it seems that Python when Python executes the above code, it creates an internal index and successively calls sequence_item(int), incrementing the index as it goes. It would be like an iterator implemented in terms of an index and an accessor function. This is different from COM's approach: internal use of an iterator object supporting Next()-like functions. Is it possible to expose the iteration capability without implementing sequence_item(int)? Your quote above suggests that it's possible, but I can't see how. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

1 0

Re: [C++-SIG] How to use CXX...
by Steve Harris May 23, 2000

May 23, 2000

"Barry Scott" <barry(a)scottb.demon.co.uk> writes: [...] > > 4. I haven't gotten to trying to wrap containers yet. What if your C++ > > type has a method like > > const std::list<foo>& get_foos() const; > > where the type exposes a nested container of some other type. That > > looks like you could coax some Pythonic behavior out of the pattern, > > but how would you go about wrapping it? Do you have to copy the whole > > list for each request for the Python-wrapped sequence? > > No copy needed. You can implement the methods required for a > sequence type and be a proxy between Python and the std::list. Looking at the sequence methods more closely, it looks like Python imposes random-access requirements on the underlying sequence. The sequence_item() method allows the caller to fetch an element at a particular index. Has anyone tried to adapt this to something like std::list? It seems like you _could_ find an item by iterating from begin() a given number of times, making sure that you're not at end(), but that's horribly inefficient. You could try to cache the last index request and say, "If the requested index is just one higher than the last one, then just bump my iterator forward by one." This could get into some weird situations if the underlying list changed - like if some elements got inserted before your "current" position. The list iterators would be stable, but the indexes would not be. An alternate idea is to copy the list iterators into a vector. That could also be costly if the proxy sequence has to be constructed again and again. Has anyone tried to create such a Standard C++ container proxy? [...] -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

2 1

Re: [C++-SIG] Trouble getting a method called
by Steve Harris May 22, 2000

May 22, 2000

Steve Harris <sharris(a)primus.com> writes: [...] > * You must call moduleDictionary() in your extension module's > constructor. Oops, I'm wrong. This call is not necessary. I think it was a rebuild problem that confused my association of this method call with the solution. I see now that moduleDictionary() is called by the initialize() function. [...] -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

1 0

Re: [C++-SIG] Trouble getting a method called
by Steve Harris May 22, 2000

May 22, 2000

"Barry Scott" <barry(a)scottb.demon.co.uk> writes: > Here is the problem. The object p does not have any attributes. > > I suggest that you add cout << debug statements to confirm that > the init_type() and getattr() are really called. I put some print statements in init_type() and verified that it is getting called. Here's what I learned: * You must have called supportGetattr() and implement getattr() for a method to be called, even if you don't care about getattr. * You must call moduleDictionary() in your extension module's constructor. Once I did those _two_ things together, my method appeared. Is this how it's supposed to work? If method calls are implemented in terms of getattr(), then calling add_varargs_method() should implicitly assert that you're "supporting getattr." Furthermore, it seems that implementing getattr shouldn't be necessary just to support method calls. After all, all my getattr() method does is forward a call to getattr_methods(). Can we invert this such that if there is no method defined for a particular getattr name, _then_ the call is (optionally) forwarded to the derived class getattr method? That is, in pseudo-code: Py::Object handle_getattr_call(const char* pcsz) { const foo::const_iterator it = method_map.find( pcsz ); if ( it != method_map.end() ) return *it; // deref it and return something callable else if ( bSupportsGetattr ) return getattr(); else throw something; } This arrangement would make more sense to me, as it better separates the method dispatching from the getattr implementation. At present, the add_varargs_method() function is confusing in that it doesn't do enough to hook up all the machinery to expose the method to Python. [...] > Make sure you have the latest sources from SourceForge. Do the latest changes address these problems? > Make sure that the Demo example module works. Yes, it does. That's where I started pulling random bits of code from (including the "moduleDictionary()" call). Why is it necessary to call this function in order for all of this to work? -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

1 0

Re: [C++-SIG] Trouble getting a method called
by Steve Harris May 22, 2000

May 22, 2000

"Barry Scott" <barry(a)scottb.demon.co.uk> writes: > Here is a check list: > > 1. init_type() must be static. Check. > 2. all the init_type() functions must be called from your modules > constructor [If not you will have no attributes] ================================================== class seh_test_module : public Py::ExtensionModule<seh_test_module> { public: seh_test_module() : Py::ExtensionModule<seh_test_module>( "seh_test" ) { py_bound_pod::init_type(); add_varargs_method( "some_pod", &seh_test_module::new_py_bound_pod, "some_pod(str)" ); initialize( "seh_test module explores wrapping a C++ POD in a Python type" ); } ================================================== Check. > 3. from python do print dir(your_module) - check for all the module > attributes >>> print dir( seh_test ) ['__doc__', '__file__', '__name__','some_pod'] Okay. > 4. from python do print dir(your_object) - check for all the object > attributes >>> p = some_pod( "a string" ) Constructing some_pod( "a string" ): 0xd8c60 >>> print dir( p ) [] Uh oh. > 5. from python do print your_object.__methods__ - check for all your > methods >>> print p.__methods__ Traceback (innermost last): File "<stdin>", line 1, in ? RuntimeError: Extension object missing a required method. Uh oh. Anything else I can check? -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com

2 1