Warnings from bjam could be nice. Maybe from a previous installation instruction set. If it is not used by bjam, makes sense to remove remaining references: https://github.com/moses-smt/mosesdecoder/blob/master/cruise-control/test_all_new_commits.sh
*Best Regards,* Ergun Ergun Biçici DFKI Projektbüro Berlin On Mon, Jan 11, 2016 at 9:56 PM, Hieu Hoang <hieuho...@gmail.com> wrote: > I'm not sure if the bjam argument > --with-giza > is actually used during compilation. Where did you see this mention? The > bad thing about bjam is it doesn't tell you if an argument is invalid, it > simply ignores it. > > It would be nice to have 1 directory for all your MT tools. If you wanna > make it happen, be my guest. > > I suppose we should be mindful of people who use mgiza but don't use > Moses, they'll still need symal so we can't just delete it from mgiza. > > On 11/01/16 18:04, Ergun Bicici wrote: > > > Hi Hieu, > > Since > > the path to mgiza is provided > during compilation, could be nice that moses knows where to look for > mgiza afterwards without additional path directives and environment > variable settings (e.g. export BINDIR=~/workspace/bin/training-tools > in <http://www.statmt.org/moses/?n=Moses.ExternalTools#ntoc3> > http://www.statmt.org/moses/?n=Moses.ExternalTools#ntoc3 instead, > I am using the following for external-bin-dir in EMS: external-bin-dir = > $moses-install-dir/bin). > > This also did not appear to work for tools in opt/ compiled with make -f > contrib/Makefiles/install-dependencies.gmake. I still added opt/lib and > opt/bin to LD_LIBRARY_PATH and PATH respectively. > > Having all binaries and libraries in the same place may decrease confusion > as well and can prevent further confusion if a file with the same name > appears in both paths. A compilation procedure that puts these directives > together (dependency compilation input to bjam) while reducing path > directives may help simplify installation. > > *Best Regards,* > Ergun > > Ergun Biçici > DFKI Projektbüro Berlin > > > On Mon, Jan 11, 2016 at 12:02 PM, Hieu Hoang <hieuho...@gmail.com> wrote: > >> you shouldn't copy anything into the moses/bin directory. >> >> The mgiza files should have its own directory. When you run Moses' >> train-model.perl you can refer to that directory using >> .../train-model.perl external-bin-dir=[directory with mgiza] >> >> >> On 10/01/16 17:20, Ergun Bicici wrote: >> >> >> Hi Hieu, >> >> First a compile: >> ./bjam --max-kenlm-order=10 --git --prefix=/path/moses/mosesdecoder/ >> --with-giza=/path/mgiza/mgizapp/inst/ >> --with-xmlrpc-c=/path/moses/mosesdecoder/opt/ >> --with-boost=/path/moses/mosesdecoder/opt/ >> --with-cmph=/path/moses/mosesdecoder/opt/ >> -j 20 >> >> then, a copy: >> cp mgiza/mgizapp/inst/bin/* moses/mosesdecoder/instdir/bin/ >> cp mgiza/mgizapp/inst/lib/* moses/mosesdecoder/instdir/lib/ >> cp mgiza/mgizapp/inst/scripts/* moses/mosesdecoder/instdir/bin/ >> >> With which another copy appears to be needed to use Moses' symal: >> cp >> moses/mosesdecoder/symal/bin/gcc-4.8/release/link-static/threading-multi/symal >> moses/mosesdecoder/bin/symal >> >> Therefore, even >> >> if the path to mgiza is provided (--with-giza=/path/mgiza/mgizapp/inst/), >> some copying and updated appear to be needed (see also >> >> <http://www.statmt.org/moses/?n=Moses.ExternalTools#ntoc3> >> http://www.statmt.org/moses/?n=Moses.ExternalTools#ntoc3). >> >> >> *Best Regards,* >> Ergun >> >> Ergun Biçici >> DFKI Projektbüro Berlin >> >> >> On Sun, Jan 10, 2016 at 3:34 PM, Hieu Hoang < <hieuho...@gmail.com> >> hieuho...@gmail.com> wrote: >> >>> What the exact commands u used to compile moses and mgiza? I'm pretty >>> sure they don't overwrite each other unless you ask them too. They're >>> independent projects >>> On 10 Jan 2016 14:07, "Ergun Bicici" < <ergun.bic...@dfki.de> >>> ergun.bic...@dfki.de> wrote: >>> >>>> >>>> Hi, >>>> >>>> I compiled another Moses instance and symal appears to be copied from >>>> mgiza still to mosesdecoder/bin/. >>>> >>>> >>>> *Best Regards,* >>>> Ergun >>>> >>>> Ergun Biçici >>>> DFKI Projektbüro Berlin >>>> >>>> >>>> On Sun, May 17, 2015 at 2:47 PM, Ergun Bicici < >>>> <ergun.bic...@computing.dcu.ie>ergun.bic...@computing.dcu.ie> wrote: >>>> >>>>> >>>>> Moses' symal: >>>>> <http://article.gmane.org/gmane.comp.nlp.moses.user/11544> >>>>> http://article.gmane.org/gmane.comp.nlp.moses.user/11544 >>>>> >>>>> >>>>> Best Regards, >>>>> Ergun >>>>> >>>>> Ergun Biçici, CNGL, School of Computing, DCU, <http://www.cngl.ie> >>>>> www.cngl.ie >>>>> <http://www.computing.dcu.ie/%7Eebicici/> >>>>> http://www.computing.dcu.ie/~ebicici/ >>>>> >>>>> >>>>> On Sun, May 17, 2015 at 1:15 PM, Jeroen Vermeulen < >>>>> <j...@precisiontranslationtools.com>j...@precisiontranslationtools.com> >>>>> wrote: >>>>> >>>>>> The symal source code is duplicated between the moses-smt and mgiza >>>>>> repositories. Does it make sense to have both? They're quietly >>>>>> diverging, which is probably a bad thing. >>>>>> >>>>>> Here's the differences that I can see: >>>>>> * I modernized the code in moses-smt. Big diff, no functional >>>>>> change. >>>>>> * The moses-smt version supports longer source and target strings. >>>>>> * The mgiza version has what looks like some extra debug output. >>>>>> * The moses-smt version avoids non-portable use of /dev/stdout. >>>>>> * One builds through bjam, the other through cmake. >>>>>> >>>>>> Could we perhaps just delete the mgiza one, and tell people to use the >>>>>> one from moses instead? >>>>>> >>>>>> >>>>>> Jeroen >>>>>> _______________________________________________ >>>>>> Moses-support mailing list >>>>>> <Moses-support@mit.edu>Moses-support@mit.edu >>>>>> <http://mailman.mit.edu/mailman/listinfo/moses-support> >>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Moses-support mailing list >>>> Moses-support@mit.edu >>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>> >>>> >> >> -- >> Hieu Hoanghttp://www.hoang.co.uk/hieu >> >> > > -- > Hieu Hoanghttp://www.hoang.co.uk/hieu > >
_______________________________________________ Moses-support mailing list Moses-support@mit.edu http://mailman.mit.edu/mailman/listinfo/moses-support
