|
Boost : |
From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2002-05-01 17:03:05
Paris (U.E.), le 01/05/2002
Uh?
I DO monitor the list, in particular so as to respond to any query
about my contributions. It is true, however that for various reasons, I
tend to lag by a few days from the latest postings.
Unresponsive strikes me as somewhap peculiar, as I believe I was for
the latest round of modifications (01/02/2002). Or perhaps three month
of stability makes a library stale?
Not all the work that is being done around the library is necessarilly
plublicised (I am working on a link with PETE, for instance), I do not
believe that it makes the library "unmaintained". Some of it is pending
upon the work of others (such as the incorporation of SPIRIT, to
simplify the input operators, or the incorporation of a matrix library
to move some of the things currently in the examples to the library
proper), so there is nothing else to do there but wait (and perhaps help
the others in their efforts).
At any rate, I was under the impression that the authors of library
were supposed to be their maintainers, unless they stated they could no
longer be considered such. I was not under the impression that more
formalism was needed there.
Finally, I will look at the proposed patch, and incorporate what I
can, in conjunction with Fredrik Blomqvist, as I did before with Douglas
Gregor for GCC 2.95.3. Coopoeration is necessary as I do not have access
to the compiler the patches are for, and I do not want to break the
compatibility with the compiler I use. Note that I *WILL NOT*
incorporate patches that would encourage the use of broken compilers at
the expense of more conforming ones. I will, of course, strive to have
the maximum number of people happy (look for lots of #ifdefs). Tolerance
is a virtue, permisiveness is not.
Bon soir
Hubert Holin
Hubert.Holin_at_[hidden]
I am not a mad scientist, I am a mad mathematician.
David Abrahams wrote:
>
> I don't think we have any formal notion of a library maintainer at
> Boost. Perhaps we should? Maybe it we should label libraries "stable but
> unmaintained" if their maintainers become unresponsive? Maybe
> unmaintained libraries should be "up for maintenance grabs" after a
> certain amount of time has passed?
>
> Hmm, where have I read these questions before?
>
> -Dave
>
> ----- Original Message -----
> From: "Fredrik Blomqvist" <f_blq_at_[hidden]>
> > Hi,
> > I just ported the quaternion and octonion package to
> > MSVC (6.0 SP5 + Dinkumware)
> > and hopefully some other compilers might benefit
> > aswell.
> > I put the changes in in the file-section as:
> > quat_oct_msvc-port.zip
> >
> >
> > Summary of changes:
> >
> >
> > quaternion.hpp / octonion.hpp:
> >
> > * changed order of the assignment-operator
> > declarations, ie put the template-version
> > _before_ the non-template version to make MSVC
> > happy.
> > (I hope this won't break any other compiler,
> > otherwise it's easily done with #ifdefs
> > also, but I tried to minimize those)
> >
> > * replaced use_facet<> with BOOST_USE_FACET
> >
> > * removed an unneccessary(?) explicit
> > function-template instantiation in the exp() func.
> >
> >
> > quaternion_test.cpp:
> >
> > * #included <boost/limits.hpp>
> >
> > * added manual abs(float/double) overloads since MSVC
> > seem to lack these(!)
> > Q: has the MSVC lack of overloads for abs() been
> > properly handled somewhere?
> > I briefly recall this issue to have been
> > discussed on boost-dev or lang.c++ but
> > I don't remeber the conclusion.
> >
> > * added manual using declarations if no
> > Koening-lookup.
> >
> > * lots of namespace tweaks, basically added explicit
> > selections instead.
> >
> >
> > octonion_test.cpp:
> >
> > - since octonion depends on quat a few fixes 'hang
> > along', (mainly using:: stuff) ok?
> >
> > * #included <boost/limits.hpp>
> >
> > * put enclosing scopes around a couple of for-loops
> > (index variable scoping)
> >
> > * lots of namespace tweaks.
> >
> >
> > sinc.hpp/sinhc.hpp:
> >
> > * added an #ifdef to allow the non template-template
> > versions to be used, this
> > enables quat/oct::exp(), cos(), sin() etc to
> > function.
> >
> >
> > All in all, everything except
> > sinc_pi/sinhc_pi<quat/oct.> should work on (atleast)
> > MSVC6 SP5 + Dinkumware. Regarding sinc_pi<quat/oct> I
> > guess a workaround for MSVC and
> > other compilers not supporting template-template
> > params could simply be do let quat/oct
> > supply it's own explicit version. But since this means
> > code-duplication (and .hpp file confusion..) I'll let
> > Hubert decide on this one.
> >
> > Hope it helps!
> > /Fredrik Blomqvist
> > fredrik_at_[hidden]
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - your guide to health and wellness
> > http://health.yahoo.com
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk