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 22:11:14 +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:
<CAEKMkbhmytAwd6VZVGzuFOPdQrDy-trMSMmQLKWWp43FD9kdRQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hieu Hoang
http://www.hoang.co.uk/hieu
On 11 January 2016 at 22:02, Ergun Bicici <ergun.bicici@dfki.de> wrote:
>
> 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
>
cheers. done
https://github.com/moses-smt/mosesdecoder/commit/bec531d0bc379f209345a2d188e25d01476248fa
>
>
>
> *Best Regards,*
> Ergun
>
> Ergun Bi?ici
> DFKI Projektb?ro Berlin
>
>
> On Mon, Jan 11, 2016 at 9:56 PM, Hieu Hoang <hieuhoang@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 <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>
>>> 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>
>>> 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>
>>>> 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>Ergun.Bicici@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 <
>>>>>> <jtv@precisiontranslationtools.com>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>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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160111/6321788b/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 22
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 111, Issue 22"
Post a Comment