Boost :

david.abrahams_at_[hidden]

---
Andy Koenig, of all people, was the keynote speaker of this year's opening
plenary session. He presented his "impressions of a polyglot outsider",
which studiously avoided any mention of C++ until the end of his talk, when
he was asked about standardization. I was surprised to learn that the C++
community at large wanted a few more years before beginning but when ANSI
accepted HP's request for a standard, the process was forced to start: it
was a matter of participating or having standardization proceed without
one's input. Andy managed to highlight very effectively the balance of
strengths in Python, one of the most important being its support for
extension via libraries. In many ways that makes Python a good analogue for
C++ in the interpreted world
There were several kind mentions of the Boost.Python library from people who
found it indispensable. I was particularly happy that Karl MacMillan,
Michael Droettboom, and Ichiro Fujinaga from Johns Hopkins is using it to do
OCR on a vast library of music notation, since in a previous life I was an
author of music notation software. These guys are also drawing on Ullrich
Koethe's VIGRA library for image manipulation (Ullrich has been a major
contributor to Boost.Python). They also have a system for writing the
Boost.Python wrapper code in C++ comments, which allows them to keep all of
the code in one place. I've asked them to send me some information on that.
The development of Swig has been gaining momentum again (the basic
description at www.boost.org/libs/python/doc/comparisons.html still
applies). The talk given about it by David Beazly was very well-attended,
and they appear to have quite a few users. Swig's strengths (coverage of
many langauages) and weaknesses (incomplete C++ language support) haven't
changed, although the C++ support seems to have improved considerably - they
now claim to have a complete model of the C++ type system. It seems to be
mostly geared at wrapping what Walter Landry calls "C-Tran": C++ code which
traffics in built-in types with little use of abstraction. I'm not knocking
that, either: I'm sure a lot of that code exists, so it's a valuable
service. One feature Swig has which I'd like to steal is the ability to
unwrap a single Python argument into multiple C++ arguments, for example, by
converting a Python string into a pointer and length. When his talk was
over, David approached me about a possible joint workshop on language
binding, which sounds like a fun idea to me.
I spent some considerable time talking with Steven Knight, the leader of the
Scons build tool effort. We had a lot to share with one another, and I
gained a much better appreciation for many of the Scons design decisions.
Scons seems to be concentrating on being the ultimate build system
substrate, and Steve seemed to think that we were on the right track with
our high-level design. We both hope that the Boost.Build V2 high-level
architecture can eventually be ported to run on top of Scons.
They also have a highly-refined and successful development procedure which
I'd like to emulate for Boost.Build V2. Among many other things they do,
their source-control system automatically ensures that when you check in a
new test, it is automatically run on the currently checked-in state of the
code, and is expected to fail -- a relatively obvious good idea which I've
never heard before.
Guido Van Rossum's "State of the Python Union" address was full of questions
for the community about what should be done next, but the one idea Guido
seemed to stress was that core language stability and continuing library
development would be a good idea (sound familiar?) I mentioned the Boost
model as a counterpoint to the idea of something like CPAN (the massive Perl
library archives), and it seemed to generate some significant interest. I've
offered to work with anyone from the Python community who wants to set up
something like Boost.
There was some discussion of "string interpolation" (variable substitution
in strings), and Guido mentioned that he had some thoughts about the
strengths/weaknesses of Python's formatting interface. It might be useful
for those working on formatting for boost to contact him and find out what
he has to say.
Ka-Ping Yee demoed a Mailman discussion thread weaver. This tool weaves the
various messages in a discussion thread into a single document so you can
follow the entire conversation. Since we're looking very seriously at moving
Boost to Mailman, this could be a really useful thing for us to have. If we
do this, we'll move the yahoogroups discussions into the mailman archive so
old discussions can be easily accessed in the same fashion.
And, just because it's cool, though perhaps not relevant:
http://homepages.ulb.ac.be/~arigo/psyco/ is a promising effort to accelerate
the execution of Python code to speeds approaching those of compiled
languages. It reminded me a lot of Todd Veldhuizen's research into moving
parts of C++ template compilation to runtime, only coming from the opposite
end of things. If you're the sort of hardcore type that is fascinated by
that stuff, they could use some help.
-Dave