Moses-support Digest, Vol 90, Issue 14

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: how to integrate a long-span LM into moses (Hieu Hoang)
2. Re: yum-installed Boost environment variables for MGIZA++ (Gideon)


----------------------------------------------------------------------

Message: 1
Date: Fri, 04 Apr 2014 13:31:29 +0100
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] how to integrate a long-span LM into
moses
To: David Mrva <davidm@cantabresearch.com>, moses-support@mit.edu
Message-ID: <533EA621.4020601@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 03/04/2014 11:55, David Mrva wrote:
> Hi moses developers,
>
> I have integrated an LM with unlimited history into moses code by
> implementing the StatefulFeatureFunction class following the example in
> moses/FF/SkeletonStatefulFF.cpp. My LM code can also handle ngrams
> through using kenlm. As kenlm is integrated into moses, I compared my
> new code with the standard moses with cs-en models. Standard moses gave
> 17.12 BLEU points and my new code with the same ini file and the same LM
> file resulted in BLEU 13.4. This lead me to read the Kenlm.cpp
> implementation in much more detail and I found a number of interesting
> aspects that I would like to understand to integrate a long-span model
> correctly.
>
> 1/ In the Evaluate(const Hypothesis &hypo, const FFState *ps,
> ScoreComponentCollection *out) const method moses/LM/Kenlm.cpp
> calculates the score over only the first N - 1 words, where N is the
> ngram order. Why not calculate the score for all words in the target
> phrase from hypo.GetCurrTargetWordsRange().GetEndPos() to
> hypo.GetCurrTargetWordsRange().GetStartPos()? Is this an optimisation or
> is it required to make the translation work?
>
> 2/ At the time of the load of the translation phrase table, moses calls:
> void LanguageModel::Evaluate(const Phrase &source, const TargetPhrase
> &targetPhrase, ScoreComponentCollection &scoreBreakdown,
> ScoreComponentCollection &estimatedFutureScore) const
> where LanguageModel is the ancestor of the LanguageModelKen<Model>
> template implemented in Kenlm.cpp. Moses calls this Evaluate() method
> for each source-target translation phrase and assigns the accumulated
> score of the first N-1 words to estimatedFutureScore and the accumulated
> score over the rest of the phrase into scoreBreakdown. What is the
> purpose of this split of the ngram scores into the first N-1 words and
> the rest of the phrase? Is the scoreBreakdown value added with the score
> calculated with the Evaluate() method from point 1/ during the search to
> get the total phrase score?
>
> 3/ The method LanguageModelKen<Model>::CalcScore(const Phrase &phrase,
> float &fullScore, float &ngramScore, size_t &oovCount) const used also
> in the calculation in point 2/ above, distinguishes between
> terminal/non-terminal words. What are these? Is the distinction relevant
> to long-span LMs? Why is the terminal/non-terminal distinction not
> necessary in the Evaluate() method described in point 1/ above?
>
> After changing my implementation to incorporate the behaviour described
> above I got an exact match of the output with moses's "native" Kenlm
> implementation. However, the behaviour in point 1/ is not suitable for
> long-span LMs and point 2/ does not make sense for non-ngram models. I
> would expect my long-span LM to operate in such a way that an LM state
> assigned to a hypothesis covers all target words from the start to the
> end of the hypothesis.
Your LM state is dependent on the entire target phrase? ie. these target
phrases have difference states:
a b c d e f g h i j
z b c d e f g h i j
This would probably negatively impact search as the stacks will have to
be pruned more often, leading to search errors.

I think this is also the experience of people trying to add syntactic LM
to SMT decoders
> And when a hypothesis is being extended, its LM
> state is extended by one target word at a time in a loop over the new
> phrase from start to finish. Ngram LM implementation does not work in
> this way and it seems to harm ngram performance. Can anyone shed some
> light on the motivation behind the behaviour described above in points 1-3?
>
> I used moses with its default, a.k.a. "normal", search algorithm (no
> [search-algorithm] variable specified in my config). For completeness,
> my config when using moses with its Kenlm class is pasted below.
>
> Best regards,
> David
>
>
> # input factors
> [input-factors]
> 0
>
> # mapping steps
> [mapping]
> 0 T 0
>
> [distortion-limit]
> 6
>
> # feature functions
> [feature]
> UnknownWordPenalty
> WordPenalty
> PhrasePenalty
> PhraseDictionaryMemory name=TranslationModel0 table-limit=20
> num-features=4 path=model/phrase-table.1.gz input-factor=0 output-factor=0
> LexicalReordering name=LexicalReordering0 num-features=6
> type=wbe-msd-bidirectional-fe-allff input-factor=0 output-factor=0
> path=model/reordering-table.1.wbe-msd-bidirectional-fe.gz
> Distortion
> KENLM lazyken=1 name=LM0 factor=0 path=lm/europarl.binlm.1 order=5
>
> # dense weights for feature functions
> [weight]
> UnknownWordPenalty0= 1
> WordPenalty0= -1
> PhrasePenalty0= 0.2
> TranslationModel0= 0.2 0.2 0.2 0.2
> LexicalReordering0= 0.3 0.3 0.3 0.3 0.3 0.3
> Distortion0= 0.3
> LM0= 0.5
>
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>



------------------------------

Message: 2
Date: Fri, 4 Apr 2014 14:59:32 +0200
From: Gideon <gidi8ster@gmail.com>
Subject: Re: [Moses-support] yum-installed Boost environment variables
for MGIZA++
To: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CALP7mvkvcOcdB9b-9r8ao2bq6tgMD989kBmak-DQKF1rNnR8yA@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks Hieu. It seems that I was missing bzip2-devel. Looks like Boost has
installed correctly now - no missing or skipped targets.

But alas, still a few errors with Moses. They are different now, so at
least all the Boost libraries are found. The log file is attached.

A warning example:

warning: No toolsets are configured.
warning: Configuring default toolset "gcc".
warning: If the default is wrong, your build may not work correctly.
warning: Use the "toolset=xxxxx" option to override our guess.
warning: For more configuration options, please consult
warning:
http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
notice: will use 'g++' for gcc, condition <toolset>gcc-4.8.2
notice: using gcc libraries :: <toolset>gcc-4.8.2 :: /usr/bin /usr/lib
/usr/lib32 /usr/lib64
notice: using gcc archiver :: <toolset>gcc-4.8.2 :: /usr/bin/ar
notice: using gcc ranlib :: <toolset>gcc-4.8.2 :: /usr/bin/ranlib
warning: toolset gcc initialization: can not find tool windres

An error example:

phrase-extract/bin/ScoreFeatureTest.test/gcc-4.8.2/release/debug-symbols-on/link-static/threading-multi/ScoreFeatureTest.o:
In function `main':
/home/kotzegj/tools/boost_1_55_0/include/boost/test/unit_test.hpp:59:
undefined reference to `boost::unit_test::unit_test_main(bool (*)(), int,
char**)'
collect2: error: ld returned 1 exit status
...failed gcc.link
phrase-extract/bin/ScoreFeatureTest.test/gcc-4.8.2/release/debug-symbols-on/link-static/threading-multi/ScoreFeatureTest...

And some others as well.

I should mention that just before re-installing Boost, I have upgraded all
packages on yum. I don't know if this is relevant.

Once again thanks for your time.

Best,

Gideon



---
gidi8ster@gmail.com
www.gideonkotze.nl
+27 78 739 8923 (Mobile)


On Fri, Apr 4, 2014 at 12:17 PM, Hieu Hoang <Hieu.Hoang@ed.ac.uk> wrote:

>
>
>
> On 4 April 2014 09:09, Gideon <gidi8ster@gmail.com> wrote:
>
>> Dear Hieu Hoang,
>>
>> I have now tried to compile Boost manually instead. There are still
>> errors, and now Moses compilation also fails. (I assumed that I should
>> re-compile Moses since it uses Boost). These were my steps:
>>
>> cd boost_1_55_0
>> ./bootstrap
>>
>> Following your advice:
>>
>> ./b2 -j4 -a --prefix=$PWD --libdir=$PWD/lib64 --layout=tagged link=static
>> threading=multi,single install || echo FAILURE
>> (-a to re-compile)
>>
>> There is one message written to standard error:
>> link.jam: No such file or directory (it does not exist anywhere in the
>> downloaded version)
>>
>> The rest is in standard output. I have attached the two files as a
>> tarball.
>>
>> Here is a typical warning:
>>
>> ./boost/concept/detail/general.hpp:71:20: warning: typedef
>> 'boost_concept_check653' locally defined but not used
>> [-Wunused-local-typedefs]
>> BOOST_PP_CAT(boost_concept_check,__LINE__)
>>
>> And an error:
>>
>> libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or
>> directory
>> #include "bzlib.h" // Julian Seward's "bzip.h" header.
>>
> I looks like the bz2 library and header file isn't installed on your
> computer. See here for how you can install it on your distribution
> http://www.statmt.org/moses/?n=Development.GetStarted
> It's likely this prevent boost_iostream lib being created. The lib file is
> usually called
> libboost_iostreams*
>
> Boost has to be ok before you can start on trying to install mgiza or Moses
>
>
>> ^
>> compilation terminated.
>>
>> Eventually:
>> ...failed updating 2 targets...
>> ...skipped 6 targets...
>> ...updated 10795 targets...
>>
>> Using your command, "ERROR" is written to output. I don't know if it is
>> fatal (i.e. if I can still use Moses and MGIZA++).
>>
>> For Moses, I assume the following is correct:
>>
>> export BOOST_ROOT=/home/kotzegj/tools/boost_1_55_0
>> export BOOST_BUILD_PATH=/home/kotzegj/tools/boost_1_55_0/boost
>>
>> I noticed that now, BOOST_ROOT does have "include", which means that
>> somehow the installation with yum is different.
>>
>> I ran bjam like this:
>>
>> ./bjam --with-irstlm=/usr/local/irstlm
>> --with-boost=/home/kotzegj/tools/boost_1_55_0 -j4 -a
>>
>> Here is a typical error:
>>
>> /usr/bin/ld: cannot find -lboost_iostreams
>>
>> collect2: error: ld returned 1 exit status
>> ...failed gcc.link
>> moses-chart-cmd/bin/gcc-4.8.2/release/debug-symbols-on/link-static/threading-multi/moses_chart...
>> gcc.compile.c++
>> moses-cmd/bin/gcc-4.8.2/release/debug-symbols-on/link-static/threading-multi/mbr.o
>>
>> I cannot find any file containing boost_iostreams under my Boost path,
>> however:
>>
>> [kotzegj@lt-2433323 boost_1_55_0]$ fnd "iostreams"
>> ./boost/iostreams
>> ./doc/html/boost_asio/example/cpp03/iostreams
>> ./libs/asio/example/cpp03/iostreams
>> ./libs/iostreams
>> ./bin.v2/libs/iostreams
>> ./include/boost/iostreams
>>
>> Perhaps this means that boost_iostreams wasn't built or something? I can
>> attach build.log.gz (of Moses) in a following email.
>>
>> Thank you for your time.
>>
>> Gideon
>>
>>
>>
>> ---
>> gidi8ster@gmail.com
>> www.gideonkotze.nl
>> +27 78 739 8923 (Mobile)
>>
>>
>> On Thu, Apr 3, 2014 at 6:43 PM, Hieu Hoang <Hieu.Hoang@ed.ac.uk> wrote:
>>
>>> I'm not too sure. Maybe you should try to compile boost yourself.
>>>
>>> The instructions are here
>>> http://www.statmt.org/moses/?n=Development.GetStarted
>>>
>>>
>>> On 3 April 2014 16:23, Gideon <gidi8ster@gmail.com> wrote:
>>>
>>>> I have done what you asked, and removed all occurrences of "-mt" in
>>>> compile.sh. However:
>>>>
>>>> /usr/bin/ld: cannot find -lboost_system
>>>> /usr/bin/ld: cannot find -lboost_thread
>>>>
>>>> /usr/bin/ld: cannot find -lpthread
>>>> /usr/bin/ld: cannot find -lstdc++
>>>> /usr/bin/ld: cannot find -lm
>>>> /usr/bin/ld: cannot find -lc
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> Two other things I noticed:
>>>>
>>>> - The script expects a $BOOST_ROOT/include, although there exists no
>>>> include directory in /home/kotzegj/tools/boost_1_54_0
>>>> - Even if I change $BOOST_ROOT to, say, "/usr" (which does contain
>>>> "include" which on its own contains "boost"), the error output is exactly
>>>> the same.
>>>>
>>>> I have run "locate boost" and attached the output in case you wanted to
>>>> look at it. Perhaps you can tell from it if I have a faulty installation?
>>>>
>>>> Thanks again.
>>>>
>>>> Gideon
>>>>
>>>>
>>>>
>>>> ---
>>>> gidi8ster@gmail.com
>>>> www.gideonkotze.nl
>>>> +27 78 739 8923 (Mobile)
>>>>
>>>>
>>>> On Thu, Apr 3, 2014 at 4:59 PM, Hieu Hoang <Hieu.Hoang@ed.ac.uk> wrote:
>>>>
>>>>> change
>>>>> -lboost_*-mt
>>>>> to
>>>>> -lboost_*
>>>>>
>>>>> i'm not sure why you're linking to stdc++, m, c.
>>>>>
>>>>> Check there's not typo in your compile.sh
>>>>>
>>>>> On 3 April 2014 15:52, Gideon <gidi8ster@gmail.com> wrote:
>>>>>
>>>>>> Thank you, I have now managed with SVN, it turns out that I had to
>>>>>> change the configuration for my (university) proxy settings. However, there
>>>>>> are still compilation errors it seems. I have warnings such as this:
>>>>>>
>>>>>> /home/kotzegj/tools/mgiza/mgizapp-code/mgizapp/src/mkcls/KategProblem.cpp:446:9:
>>>>>> warning: deprecated conversion from string constant to 'char*'
>>>>>> [-Wwrite-strings]
>>>>>> in="other ";
>>>>>>
>>>>>> And perhaps more importantly, some files that are not found:
>>>>>>
>>>>>> /usr/bin/ld: cannot find -lboost_system-mt
>>>>>> /usr/bin/ld: cannot find -lboost_thread-mt
>>>>>> /usr/bin/ld: cannot find -lpthread
>>>>>> /usr/bin/ld: cannot find -lstdc++
>>>>>> /usr/bin/ld: cannot find -lm
>>>>>> /usr/bin/ld: cannot find -lc
>>>>>>
>>>>>> which would indicate that there are still some problems with
>>>>>> (finding) Boost.
>>>>>>
>>>>>> And still no mgiza binary.
>>>>>>
>>>>>> Some context (fnd is an alias for "find . -name"):
>>>>>>
>>>>>> [kotzegj@lt-2433323 usr]$ fnd "*boost_thread*"
>>>>>> ./lib64/libboost_thread.so
>>>>>> ./lib64/libboost_thread.so.1.54.0
>>>>>>
>>>>>> [kotzegj@lt-2433323 usr]$ fnd "*boost_system*"
>>>>>> ./lib64/libboost_system.so.1.54.0
>>>>>> ./lib64/libboost_system.so
>>>>>>
>>>>>> As mentioned, I installed Boost using yum, and these are my current
>>>>>> variables in compile.sh:
>>>>>>
>>>>>> SRC_DIR=/home/kotzegj/tools/mgiza/mgizapp-code/mgizapp/src
>>>>>> BOOST_ROOT=/home/kotzegj/tools/boost_1_54_0
>>>>>> BOOST_LIBRARYDIR=/usr/lib64
>>>>>>
>>>>>> BOOST_ROOT is pointing to the uncompiled unbuilt Boost - perhaps it
>>>>>> should point somewhere else?
>>>>>>
>>>>>> Thank you for your time.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Gideon Kotz?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> gidi8ster@gmail.com
>>>>>> www.gideonkotze.nl
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 3, 2014 at 3:05 PM, Hieu Hoang <Hieu.Hoang@ed.ac.uk>wrote:
>>>>>>
>>>>>>> You should use the version in svn, rather than a packaged version.
>>>>>>> mgiza isn't really looked after by anyone anymore, bug fixes go straight
>>>>>>> into the svn and nowhere else.
>>>>>>>
>>>>>>> I've just pushed a fix for a minor OSX compile error
>>>>>>> https://sourceforge.net/p/mgizapp/code/48/
>>>>>>>
>>>>>>> Try to download it via svn. If it doesn't work, i will consider
>>>>>>> moving it to github.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2 April 2014 14:34, Gideon <gidi8ster@gmail.com> wrote:
>>>>>>>
>>>>>>>> Dear Hieu Hoang
>>>>>>>>
>>>>>>>> Thank you for you reply. I made some changes:
>>>>>>>>
>>>>>>>> - uncommented out the top variables and commented out the Mac ones
>>>>>>>> - set BOOST_ROOT to /home/kotzegj/tools/boost_1_54_0 and
>>>>>>>> BOOST_LIBRARYDIR to /usr/lib64
>>>>>>>> - set SRC_DIR to /home/kotzegj/tools/mgiza/mgizapp/src
>>>>>>>>
>>>>>>>> and ran ./compile.sh.
>>>>>>>>
>>>>>>>> Two issues remain so far:
>>>>>>>>
>>>>>>>> 1) I can't find any MGIZA++/mgiza++/etc. binary (find . -name). Is
>>>>>>>> there a way to test if MGIZA++ has installed correctly? I did not notice
>>>>>>>> any other error messages, apart from the files the script tries to remove
>>>>>>>> at the beginning, which do not exist.
>>>>>>>>
>>>>>>> it should be called
>>>>>>> manual-compile/mgiza
>>>>>>> If not, there was a compile error
>>>>>>>
>>>>>>>>
>>>>>>>> 2) When compiling, this warning pops up all the time (you are
>>>>>>>> probably aware of it)
>>>>>>>>
>>>>>>>> /usr/include/c++/4.8.2/backward/backward_warning.h:32:2: warning:
>>>>>>>> #warning This file includes at least one deprecated or antiquated header
>>>>>>>> which may be removed without further notice at a future date. Please use a
>>>>>>>> non-deprecated interface with equivalent functionality instead. For a
>>>>>>>> listing of replacement headers and interfaces, consult the file
>>>>>>>> backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp]
>>>>>>>>
>>>>>>>> So I assume this is OK for now but there needs to be an update in
>>>>>>>> the future?
>>>>>>>>
>>>>>>> i see it. Be my guest if you wanna update it
>>>>>>>
>>>>>>>>
>>>>>>>> and (just to test)
>>>>>>>>
>>>>>>>> 2) [kotzegj@lt-2433323 manual-compile]$ ./mkcls
>>>>>>>> ERROR: can not open file train.
>>>>>>>> Error: Could not read the file 'train'.
>>>>>>>>
>>>>>>>> But perhaps this is the default?
>>>>>>>>
>>>>>>> I don't know. Try running it with valid arguments, eg
>>>>>>>
>>>>>>> http://www.statmt.org/moses/RELEASE-2.1/models/cs-en/steps/1/TRAINING_prepare-data.1.STDERR
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 3) svn checkout http://svn.code.sf.net/p/mgizapp/code/trunkmgizapp-code
>>>>>>>> --> did not work (timeout). I downloaded 0.7.3 from here instead:
>>>>>>>> http://www.kyloo.net/software/doku.php/mgiza:overview
>>>>>>>>
>>>>>>>> svn: E000110: Unable to connect to a repository at URL '
>>>>>>>> http://svn.code.sf.net/p/mgizapp/code/trunk'
>>>>>>>> svn: E000110: Error running context: Connection timed out
>>>>>>>>
>>>>>>>> Thank you for your time.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Gideon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> gidi8ster@gmail.com
>>>>>>>> www.gideonkotze.nl
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 2, 2014 at 2:38 PM, Hieu Hoang <hieuhoang@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> the cmake build system on mgiza is difficult to use.
>>>>>>>>>
>>>>>>>>> I create an alternative compile script for mgiza. If you've
>>>>>>>>> download mgiza via svn, you should find my script in
>>>>>>>>> mgizapp/manual-compile/compile.sh
>>>>>>>>> Look at it, change the paths for your own needs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/04/2014 11:34, Gideon wrote:
>>>>>>>>>
>>>>>>>>> Dear Moses support team
>>>>>>>>>
>>>>>>>>> I was wondering if MGIZA++ has been test-compiled on a Fedora
>>>>>>>>> Linux system where Boost has been installed using yum, as I'm encountering
>>>>>>>>> some problems. I'm working on a Fedora 20 system with x86_64 architecture.
>>>>>>>>> So far I have done the following:
>>>>>>>>>
>>>>>>>>> yum install boost.x86_64
>>>>>>>>> yum install boost-devel.x86_64 (version 1.54 was installed)
>>>>>>>>> yum install gcc
>>>>>>>>> yum install gcc-c++
>>>>>>>>> yum install gperftools
>>>>>>>>> Downloaded and installed IRSTLM
>>>>>>>>> ./bjam --with-irstlm=/home/kotzegj/tools/irstlm-5.80.03 -j4
>>>>>>>>> --with-boost=/usr/lib64
>>>>>>>>> export BOOST_ROOT=/usr/lib64
>>>>>>>>> export
>>>>>>>>> BOOST_BUILD_PATH=/home/kotzegj/tools/mosesdecoder/jam-files/boost-build
>>>>>>>>> ./bjam --with-irstlm=/usr/local/irstlm -j4
>>>>>>>>>
>>>>>>>>> I have tested Moses with sample-models and it seems OK.
>>>>>>>>>
>>>>>>>>> However, MGIZA++ does not find Boost on its own:
>>>>>>>>>
>>>>>>>>> -- Could NOT find Boost
>>>>>>>>> CMake Error at CMakeLists.txt:59 (MESSAGE):
>>>>>>>>> Boost not found, please set the BOOST_ROOT and BOOST_LIBRARYDIR
>>>>>>>>> environment
>>>>>>>>> variables
>>>>>>>>>
>>>>>>>>> I have no success with setting either of these variables to:
>>>>>>>>>
>>>>>>>>> - /usr/lib64
>>>>>>>>> - /usr/include
>>>>>>>>> - /usr/include/boost
>>>>>>>>> - /home/kotzegj/tools/mosesdecoder/jam-files/boost-build
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> or if I download Boost manually, set the decompressed directory
>>>>>>>>> as BOOST_ROOT, and symlink lib64 as a child and set that as
>>>>>>>>> BOOST_LIBRARYDIR. (I've tried all kinds of stuff.)
>>>>>>>>>
>>>>>>>>> I have the feeling (after some Googling) that the yum
>>>>>>>>> installation does not result in the file structure that cmake is looking
>>>>>>>>> for, and that instead I should try a manual installation. I hope that I'm
>>>>>>>>> wrong?
>>>>>>>>>
>>>>>>>>> Thank you for your time.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Gideon Kotz?
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> gidi8ster@gmail.com
>>>>>>>>> www.gideonkotze.nl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moses-support mailing listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moses-support mailing list
>>>>>>>>> Moses-support@mit.edu
>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hieu Hoang
>>>>>>> Research Associate
>>>>>>> University of Edinburgh
>>>>>>> http://www.hoang.co.uk/hieu
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hieu Hoang
>>>>> Research Associate
>>>>> University of Edinburgh
>>>>> http://www.hoang.co.uk/hieu
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Hieu Hoang
>>> Research Associate
>>> University of Edinburgh
>>> http://www.hoang.co.uk/hieu
>>>
>>>
>>
>
>
> --
> Hieu Hoang
> Research Associate
> University of Edinburgh
> http://www.hoang.co.uk/hieu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20140404/18187b03/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log.gz
Type: application/x-gzip
Size: 111230 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/moses-support/attachments/20140404/18187b03/attachment.bin

------------------------------

_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


End of Moses-support Digest, Vol 90, Issue 14
*********************************************

Tweet