Re: Re: method_call_expr not supported by dump_expr

--- David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> wrote:
> I doubt it.  Everything interesting happens in evaluating the sizeof
> expression.  If they're not having problems now, they're not likely
> to start.
> 
> > , while Romain's fix is
> > minimally intrusive and does not change the code seen by compilers other
> than
> > gcc 3.3.
> > Your choice: adventurous or conservative?
> 
> adventurous.

Ay-ay, sir!

I am already in trouble, so I backed up:

- checked out current boost CVS (~1 hour ago)
- compiled my scitbx with default Redhat 8 gcc 3.2: no problems
- trying to compile with gcc 3.3 under Redhat 8 after completely disabling the
assertion at line 28 of as_to_python_function.hpp. Here is the full
stlfilt'ered error message:

http://cci.lbl.gov/~rwgk/tmp/gcc33_linux_flex_scitbx_ext_error

The file being compiled is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/flex_scitbx_ext.cpp?rev=1.7&content-type=text/vnd.viewcvs-markup

The error message ends with:

boost::python::optional<
const
double &, boost::mpl::void_, boost::mpl::void_, ... boost::mpl::void_>
>::sequence2' is private

I remember that this worked before you checked in the fairly massive set of
fixes a couple of days ago. Did something nasty creep in?

Ralf



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com