On 4 Apr 2010 at 19:29, troy d. straszheim wrote: > The first main change was to gut a bunch of the old preprocessor gunk > and replace with boost.fusion. This would make my branch incompatible > with Niall's threadsafety changes; on the other hand, it would probably > be much easier to implement them. as<...> and scored overload > resolution are built on top of the fusionization stuff. I've removed a > great many old workaround #ifdefs.
If I have to rewrite the patch because you have eliminated preprocessor complexity then I am extremely happy! Back in the day when I was first developing the patch there was a discussion about how best to modularise the threading support such that *any* threading system could be added. The upshot that I remember (and I might add that my memory is definitely increasingly rewriting itself with age) was that Boost was going to be getting its own threading support module and then thereafter C++ itself. I have a vague recollection of strongly criticising the POSIX thread API which in my opinion is very poorly thought through, and then a discussion erupted about how a proper threading API should look. Needless to say, it all culminated in nothing. I think, with hindsight, that we all were going at it wrong at that time. What we *ought* to have been doing is an upcall mechanism such that routine X is always called just before entering C++ space and routine Y is always called just before entering Python space. That way you get the best of all worlds. > * None of it is integrated with boost.build: the branch builds against > any boost >= 1.38 or so. It uses CMake. I've said it before and I'll say it again: Boost.Python ought to have SCons build files in there as standard. Moreover, SCons just keeps on getting better with age too, the most recent version allowed me to greatly simplify my previous SCons setup. It's getting a real good balance of power and simplicity, though the learning curve is still extremely steep. > - Figure out what else should go in there, e.g. > > --- Niall's threadsafety patches > --- the recent std::ostream& stuff > --- better indexing suites (I have an improved map_indexing_suite > sitting around that should go in) > --- maybe some of your numpy stuff? > --- things laying around on various wiki pages > --- docs, docs, docs > --- examples, examples, examples > > - Get all that implemented separate from boost trunk, beat on it at > length, including having "power users" actually try it with their > production apps: py++, TnFOX, my physics stuff, etc. > > Then boost.buildize and commit wholesale back to trunk. That's my two > cents, anyway. The older I get the more I like encapsulating-but-abstracting template parameter classes. I think that the threading support is best implemented as a simple upcall hook for C++ <=> Python traversal, then you get lots of other potential applications of the upcall too. This time last year I had thought that I'd have GSoc mentoring time during the summer. I'm sure had I been allocated a slot I'd have created the time, but as it happened most of the summer got sucked up in all sorts of unforeseen events created by the starting of my consulting company. This summer shouldn't be so unpredictable - I might even get a TnFOX release out, hopefully with OpenCL and AVX support - but sadly paying work must take precedence above all else. I like consulting more than any other job I've ever had, but I do find that paying work tends to skirt major refactoring in favour of patching up cracks even if it costs them a lot more in the long run. Understandable I suppose given the money hole refactoring can become. Anyway, if you'd like me to contribute the generic upcall support complete with docs and unit tests to your new code branch then let me know. I'll create the time necessary :) Cheers, Niall _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
