Send Moses-support mailing list submissions to
moses-support@mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu
You can reach the person managing the list at
moses-support-owner@mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."
Today's Topics:
1. Re: Which symal? (Hieu Hoang)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Jan 2016 20:56:49 +0000
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] Which symal?
To: Ergun Bicici <ergun.bicici@dfki.de>
Cc: moses-support <moses-support@mit.edu>
Message-ID: <56941711.8020000@gmail.com>
Content-Type: text/plain; charset="utf-8"
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 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 <hieuhoang@gmail.com
> <mailto:hieuhoang@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).
>>
>>
>> /Best Regards,/
>> Ergun
>>
>> Ergun Bi?ici
>> DFKI Projektb?ro Berlin
>>
>>
>> On Sun, Jan 10, 2016 at 3:34 PM, Hieu Hoang <hieuhoang@gmail.com
>> <mailto:hieuhoang@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.bicici@dfki.de
>> <mailto:ergun.bicici@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.Bicici@computing.dcu.ie
>> <mailto:Ergun.Bicici@computing.dcu.ie>> wrote:
>>
>>
>> Moses' symal:
>> http://article.gmane.org/gmane.comp.nlp.moses.user/11544
>>
>>
>> Best Regards,
>> Ergun
>>
>> Ergun Bi?ici, CNGL, School of Computing, DCU,
>> www.cngl.ie <http://www.cngl.ie>
>> http://www.computing.dcu.ie/~ebicici/
>> <http://www.computing.dcu.ie/%7Eebicici/>
>>
>>
>> On Sun, May 17, 2015 at 1:15 PM, Jeroen Vermeulen
>> <jtv@precisiontranslationtools.com
>> <mailto:jtv@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 <mailto:Moses-support@mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>>
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu <mailto:Moses-support@mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
> --
> Hieu Hoang
> http://www.hoang.co.uk/hieu
>
>
--
Hieu Hoang
http://www.hoang.co.uk/hieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160111/0aae7f20/attachment.html
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 111, Issue 20
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 111, Issue 20"
Post a Comment