Kenneth, I think that new functionality such as what you're implementing is a strong argument for requiring Boost. You and other active developers should not be put into the situation where you have to reimplement Boost functionality.
Would a requirement on Boost headers get you the tools that you need and want to use in developing new features? Lane On Thu, Sep 22, 2011 at 2:57 PM, Kenneth Heafield <[email protected]> wrote: > I'm working on modified Kneser-Ney estimation using bounded memory but > it depends on a Boost released in the last year. Would you take that > trade, installing Boost so you don't have to install SRILM or IRSTLM? >> Kenneth, >> >> I completely sympathize with you. Unfortunately, there are places >> (such as where I work) where stability is important, and a major >> mechanism for achieving stability is the use of an enterprise-level >> Linux distro; such distros by design use older versions of most >> software. >> >> I have frequently found myself being the voice pushing for more recent >> software, and in fact we are (very slowly) transitioning to a more >> modern distro. But the point remains that there is value in being able >> to compile Moses on older distributions (like Centos 5.x) and newer >> platforms (like iOS and Android). > There are probably many similarly trapped people. I remember the pain > that Tim Anderson went through with MEMT. Few of them seem to be taking > the survey, but they'll probably start shouting if/when Moses starts > depending on Boost. > > So far as compiling for a "new" platform, it's not hard to compile Boost > for ARM once you're already doing the cross-compile legwork. >> I haven't been involved in the Moses coding surrounding multithreading >> and its use of Boost. While there is value in the ability to compile >> Moses on the platforms I mentioned above, Hieu's point is very valid - >> it would be much better from a testing and bug-prevention perspective >> to have fewer code paths to examine. It may even be that this factor >> is important enough to justify changes that would make it harder or >> impossible to compile on less used, older platforms. > Also, I'm tired of reimplementing Boost. >> I guess my main point is that as decisions are made, keep in mind how >> those changes will affect users on older distribution, as well as >> development on newer platforms. >> >> I like your suggestion of using only Boost headers instead of Boost >> libraries for any mandatory Boost dependencies. > Anybody else want to comment? I'm looking forward to some scoped_ptr > and unordered_map. Functionally, the build process for unfortunate > users looks like this: > > wget -O - > http://sourceforge.net/projects/boost/files/boost/1.47.0/boost_1_47_0.tar.bz2/download > |tar xj > export CPATH=$PWD/boost_1_47_0 > cd mosesdecoder > ./regenerate-makefiles.sh > ./configure > make -j8 > >> As far as multi-threaded versus single-threaded, I am fine with >> removing the single-threaded option if that would make development and >> maintenance easier. (Now that I've said that, does multi-threading >> depend on Boost?) > Multi-threading is implemented using Boost threads. >> Cheers, >> Lane > > -- When a place gets crowded enough to require ID's, social collapse is not far away. It is time to go elsewhere. The best thing about space travel is that it made it possible to go elsewhere. -- R.A. Heinlein, "Time Enough For Love" _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
