Moses-support Digest, Vol 111, Issue 64

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: kbmira died with SIGABRT when tuning (Dingyuan Wang)
2. Job: Researcher in Statistical MT at the University of
Edinburgh (Barry Haddow)
3. Re: mgiza signal 11 coredump (Matjaz Rihtar)


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

Message: 1
Date: Wed, 20 Jan 2016 20:28:52 +0800
From: Dingyuan Wang <abcdoyle888@gmail.com>
Subject: Re: [Moses-support] kbmira died with SIGABRT when tuning
To: Barry Haddow <bhaddow@staffmail.ed.ac.uk>, Hieu Hoang
<hieuhoang@gmail.com>
Cc: moses-support <moses-support@mit.edu>
Message-ID: <569F7D84.2010004@gmail.com>
Content-Type: text/plain; charset=utf-8

Hi Barry,

I suspect it may be a memory related problem. I've tested it on a VPS
and no errors for 111 iterations.
The laptop I use passed two passes of memtest86+, but I'm not sure.

Both machines are latest Debian testing (8.1+).

? 2016?01?20? 18:20, Barry Haddow ??:
> Hi Dingyuan
>
> What platform are you running on? I could not reproduce your error on
> Ubuntu 12.04, and valgrind is clean,
>
> cheers - Barry
>
> On 19/01/16 16:31, Barry Haddow wrote:
>> Hi Dingyuan
>>
>> I ran for over 200 iterations and saw no problem. I tried with your LANG
>> and LANGUAGE settings (I don't have the right packages for the other
>> settings) and still saw no failure.
>>
>> Maybe it is a random pointer/memory problem like you suggested. I have
>> started running your model with valgrind, but nothing so far,
>>
>> cheers - Barry
>>
>> On 19/01/16 14:26, Dingyuan Wang wrote:
>>> Hi Barry,
>>>
>>> It usually hits an error in about 1~10 iterations on my laptop. I don't
>>> know what triggers that, so it may be a probability problem.
>>>
>>> Disabling xml-input won't help. I think I should use verbose output.
>>>
>>> My locale settings is:
>>>
>>> LANG=zh_CN.UTF-8
>>> LANGUAGE=zh_CN.UTF-8:zh_TW.UTF-8:zh_HK.utf8:en_US.utf8
>>> LC_CTYPE="zh_CN.UTF-8"
>>> LC_NUMERIC="zh_CN.UTF-8"
>>> LC_TIME="zh_CN.UTF-8"
>>> LC_COLLATE="zh_CN.UTF-8"
>>> LC_MONETARY="zh_CN.UTF-8"
>>> LC_MESSAGES="zh_CN.UTF-8"
>>> LC_PAPER="zh_CN.UTF-8"
>>> LC_NAME="zh_CN.UTF-8"
>>> LC_ADDRESS="zh_CN.UTF-8"
>>> LC_TELEPHONE="zh_CN.UTF-8"
>>> LC_MEASUREMENT="zh_CN.UTF-8"
>>> LC_IDENTIFICATION="zh_CN.UTF-8"
>>> LC_ALL=
>>>
>>> ? 2016?01?19? 19:20, Barry Haddow ??:
>>>> Hi Dingyuan
>>>>
>>>> I have your script and model running, but so far it has not reported
>>>> any
>>>> errors. It's at iteration 27, and I'm using the latest Moses from git.
>>>>
>>>> How long should I expect it to run before it hits an error? Could it be
>>>> affected by the locale setting?
>>>>
>>>> Have you tried running without xml-input to see if you still have the
>>>> problem?
>>>>
>>>> cheers - Barry
>>>>
>>>> On 19/01/16 05:43, Dingyuan Wang wrote:
>>>>> Hi Barry,
>>>>>
>>>>> I've uploaded the model:
>>>>> https://mega.nz/#!UsVSBCBJ!e5IATFvLqrCb5zhmDekLn8NOGw4PSD9RRQLGQeKEvNY
>>>>>
>>>>> To test the model, I included a script 'repeatnbest.sh' which runs
>>>>> moses
>>>>> repeatedly until encoding error occurs.
>>>>>
>>>>> The file run7.best100.out and run7.out in the archive is the last run
>>>>> that produces the error.
>>>>>
>>>>> It seems that it is WordTranslationFeature that causes the problem.
>>>>>
>>>>> ? 2016?01?19? 00:03, Barry Haddow ??:
>>>>>> Hi Dingyuan
>>>>>>
>>>>>> Something is going wrong with the construction or outputting of
>>>>>> feature
>>>>>> names, and it looks like it's WordTranslationFeature that's the
>>>>>> problem.
>>>>>> Does the problem go away if you do not use word translation features?
>>>>>>
>>>>>> If you could make available a model that reproduces the nbest list
>>>>>> construction then I would have a chance to debug it,
>>>>>>
>>>>>> cheers - Barry
>>>>>>
>>>>>> On 18/01/16 15:32, Dingyuan Wang wrote:
>>>>>>> Hi Barry,
>>>>>>>
>>>>>>> I've checked all the models and corpora with the script, without
>>>>>>> finding
>>>>>>> any encoding problem.
>>>>>>>
>>>>>>> I also find that all such errors in nbest list occurs only in the
>>>>>>> feature list (3 different samples), without affecting translation
>>>>>>> result. Therefore, the phrase table or training corpus may not be
>>>>>>> the
>>>>>>> problem.
>>>>>>>
>>>>>>> ? 2016?01?18? 23:04, Barry Haddow ??:
>>>>>>>> Hi Dingyuan
>>>>>>>>
>>>>>>>> Are these encoding errors present in your phrase table? Are they
>>>>>>>> present
>>>>>>>> in your training corpus? Since they appear in the word translation
>>>>>>>> features, and you are using a shortlist, are they in the shortlist
>>>>>>>> files
>>>>>>>> in the model directory? (These have names with "topn" in them
>>>>>>>> afaik).
>>>>>>>>
>>>>>>>> File-system errors are unlikely, and for the most part Moses treats
>>>>>>>> text
>>>>>>>> as byte strings so encoding errors usually trace back to the source
>>>>>>>> text.
>>>>>>>>
>>>>>>>> cheers - Barry
>>>>>>>>
>>>>>>>> On 18/01/16 14:56, Dingyuan Wang wrote:
>>>>>>>>> Hi Barry,
>>>>>>>>>
>>>>>>>>> "The ones starting with the "@"" are due to corrupted bytes in the
>>>>>>>>> nbest
>>>>>>>>> list.
>>>>>>>>>
>>>>>>>>> This kind of corruption occurs from time to time. I wonder if it
>>>>>>>>> comes
>>>>>>>>> from memory errors or filesystem failure or some kind of
>>>>>>>>> pointer/encoding problem in moses.
>>>>>>>>>
>>>>>>>>> I've written a script to find such corrupted lines:
>>>>>>>>>
>>>>>>>>> https://gist.github.com/gumblex/0d9d0848b435e4f9818f
>>>>>>>>>
>>>>>>>>> ? 2016?01?18? 20:42, Barry Haddow ??:
>>>>>>>>>> Hi Dingyuan
>>>>>>>>>>
>>>>>>>>>> The extractor expects feature names to contain an underscore (not
>>>>>>>>>> sure
>>>>>>>>>> exactly why) but some of yours don't, and Moses skips them,
>>>>>>>>>> interpreting
>>>>>>>>>> their values as extra dense features.
>>>>>>>>>>
>>>>>>>>>> The attached screenshot shows my view of the offending names. The
>>>>>>>>>> ones
>>>>>>>>>> starting with the "@" are the problem. So it does look like the
>>>>>>>>>> nbest
>>>>>>>>>> list is corrupted. Can you run the decoder on just that
>>>>>>>>>> sentence, to
>>>>>>>>>> create an uncompressed version of the nbest list?
>>>>>>>>>>
>>>>>>>>>> cheers - Barry
>>>>>>>>>>
>>>>>>>>>> On 18/01/16 12:02, Dingyuan Wang wrote:
>>>>>>>>>>> Hi Barry,
>>>>>>>>>>>
>>>>>>>>>>> Attached is the zgrep result.
>>>>>>>>>>> I found that in the middle of line 61 a few bytes are
>>>>>>>>>>> corrupted. Is
>>>>>>>>>>> that
>>>>>>>>>>> a moses problem or my memory has a problem?
>>>>>>>>>>>
>>>>>>>>>>> I also checked other files using iconv, they are all OK in
>>>>>>>>>>> UTF-8.
>>>>>>>>>>>
>>>>>>>>>>> ? 2016?01?18? 19:32, Barry Haddow ??:
>>>>>>>>>>>> Hi Dingyuan
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, that's very possible. The error could be in extracting
>>>>>>>>>>>> features.dat
>>>>>>>>>>>> from the nbest list. Are you able to post the nbest list? Or at
>>>>>>>>>>>> least
>>>>>>>>>>>> the entries for sentence 16?
>>>>>>>>>>>>
>>>>>>>>>>>> Run something like
>>>>>>>>>>>>
>>>>>>>>>>>> zgrep "^16 " tuning/tmp.1/run7.best100.out.gz
>>>>>>>>>>>>
>>>>>>>>>>>> cheers - Barry
>>>>>>>>>>>>
>>>>>>>>>>>> On 18/01/16 11:24, Dingyuan Wang wrote:
>>>>>>>>>>>>> Hi Barry,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have rerun the ems after the first email, and then posted
>>>>>>>>>>>>> the
>>>>>>>>>>>>> recent
>>>>>>>>>>>>> results, so the line changed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just use the latest code, and the EMS script. Pretty much
>>>>>>>>>>>>> are
>>>>>>>>>>>>> default
>>>>>>>>>>>>> settings. The EMS setting is:
>>>>>>>>>>>>>
>>>>>>>>>>>>> sparse-features = "target-word-insertion top 50,
>>>>>>>>>>>>> source-word-deletion
>>>>>>>>>>>>> top 50, word-translation top 50 50, phrase-length"
>>>>>>>>>>>>>
>>>>>>>>>>>>> I suspect there is something unexpected in the extractor.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ? 2016?01?18? 19:03, Barry Haddow ??:
>>>>>>>>>>>>>> Hi Dingyuan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In fact it is not the sparse features nor the Asian
>>>>>>>>>>>>>> characters
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> the problem. The offending line has 17 dense features, yet
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> model
>>>>>>>>>>>>>> has 14 dense features.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The string "1 1 1" appears directly after the language model
>>>>>>>>>>>>>> feature in
>>>>>>>>>>>>>> line 1694, in your attachment, adding the extra 3
>>>>>>>>>>>>>> features. Note
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> this is not the line you mentioned in your earlier email.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have no idea why there are extra features. Have you made
>>>>>>>>>>>>>> changes to
>>>>>>>>>>>>>> any of the core Moses features?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> best wishes
>>>>>>>>>>>>>> Barry
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The offending line:
>>>>>>>>>>>>>> what(): Error in line "-5.44027 0 0 -5.34901 0 0 0
>>>>>>>>>>>>>> -224.872 1 1
>>>>>>>>>>>>>> 1 -39
>>>>>>>>>>>>>> 18 -26.2331 -40.6736 -44.3698 -82.5072 WT_?~?=3 WT_?~?=1
>>>>>>>>>>>>>> WT_?~?=1
>>>>>>>>>>>>>> WT_?~?=1 WT_?~?=1 PL_s3=5 PL_3,2=2 PL_3,3=3 PL_2,3=4
>>>>>>>>>>>>>> PL_t3=7
>>>>>>>>>>>>>> PL_s1=5
>>>>>>>>>>>>>> PL_1,2=2 PL_1,1=3 PL_t1=4 PL_2,2=3 PL_t2=7 PL_s2=8
>>>>>>>>>>>>>> PL_2,1=1 WT_
>>>>>>>>>>>>>> ?~?=1
>>>>>>>>>>>>>> WT_?~?=1 WT_?~?=1 WT_?~?=1 WT_?~?=1 WT_?~?=1 WT_?~
>>>>>>>>>>>>>> ?=1
>>>>>>>>>>>>>> WT_?~
>>>>>>>>>>>>>> ?=1 WT_??~?=1 WT_??~?=1 WT_?~?=1 WT_?~?=1 WT_?~?
>>>>>>>>>>>>>> ?=1
>>>>>>>>>>>>>> WT_?~
>>>>>>>>>>>>>> ?=1 WT_?~?=1 WT_?~??=1 WT_?~??=1 WT_?~?=1 WT_
>>>>>>>>>>>>>> ?~?=1
>>>>>>>>>>>>>> WT_
>>>>>>>>>>>>>> ?~?
>>>>>>>>>>>>>> ?=1 WT_?~?=1 WT_?~??=1 WT_?~?=1 WT_?~??=1 WT_?~?
>>>>>>>>>>>>>> ?=1
>>>>>>>>>>>>>> WT_?
>>>>>>>>>>>>>> ?~??=1 WT_?~??=1 WT_?~?=1 WT_?~?=1 WT_?~?=1
>>>>>>>>>>>>>> WT_?~?
>>>>>>>>>>>>>> ?=1 WT_
>>>>>>>>>>>>>> ?~??=1 WT_??~??=1 " of ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 18/01/16 10:37, Dingyuan Wang wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've attached that. The line number is 1694.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ? 2016?01?18? 16:43, Barry Haddow ??:
>>>>>>>>>>>>>>>> Hi Dingyuan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is it possible to attach the features.dat file that is
>>>>>>>>>>>>>>>> causing the
>>>>>>>>>>>>>>>> error? Almost certainly Moses is failing to parse the line
>>>>>>>>>>>>>>>> because of
>>>>>>>>>>>>>>>> the Asian characters in the feature names,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cheers - Barry
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 16/01/16 15:58, Dingyuan Wang wrote:
>>>>>>>>>>>>>>>>> I ran
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ~/software/moses/bin/kbmira -J 75 --dense-init run7.dense
>>>>>>>>>>>>>>>>> --sparse-init
>>>>>>>>>>>>>>>>> run7.sparse-weights --ffile run1.features.dat --ffile
>>>>>>>>>>>>>>>>> run2.features.dat
>>>>>>>>>>>>>>>>> --ffile run3.features.dat --ffile run4.features.dat
>>>>>>>>>>>>>>>>> --ffile
>>>>>>>>>>>>>>>>> run5.features.dat --ffile run6.features.dat --ffile
>>>>>>>>>>>>>>>>> run7.features.dat
>>>>>>>>>>>>>>>>> --scfile run1.scores.dat --scfile run2.scores.dat --scfile
>>>>>>>>>>>>>>>>> run3.scores.dat --scfile run4.scores.dat --scfile
>>>>>>>>>>>>>>>>> run5.scores.dat
>>>>>>>>>>>>>>>>> --scfile run6.scores.dat --scfile run7.scores.dat -o
>>>>>>>>>>>>>>>>> /tmp/mert.out
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> in the tuning/tmp.1 directory, which will certainly
>>>>>>>>>>>>>>>>> replicate the
>>>>>>>>>>>>>>>>> error.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ? 2016?01?16? 23:42, Hieu Hoang ??:
>>>>>>>>>>>>>>>>>> The mert script prints out every command it runs. You
>>>>>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>> replicate the error by running the last command
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 16 Jan 2016 14:18, "Dingyuan Wang"
>>>>>>>>>>>>>>>>>> <abcdoyle888@gmail.com
>>>>>>>>>>>>>>>>>> <mailto:abcdoyle888@gmail.com>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sorry, but I can't reliably replicate the
>>>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> running
>>>>>>>>>>>>>>>>>> TUNING_tune.1 alone. There is no
>>>>>>>>>>>>>>>>>> character '_' in
>>>>>>>>>>>>>>>>>> the test
>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>> or top50
>>>>>>>>>>>>>>>>>> list.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm using sparse-features =
>>>>>>>>>>>>>>>>>> "target-word-insertion
>>>>>>>>>>>>>>>>>> top 50,
>>>>>>>>>>>>>>>>>> source-word-deletion top 50,
>>>>>>>>>>>>>>>>>> word-translation
>>>>>>>>>>>>>>>>>> top 50
>>>>>>>>>>>>>>>>>> 50,
>>>>>>>>>>>>>>>>>> phrase-length"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've attached some related files from EMS
>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>> EMS
>>>>>>>>>>>>>>>>>> config.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://mega.nz/#!xs0SFKxL!M_RTBp1JGX24-b4xlYYLP-bLXKiC_Sl-p96x55avAB4
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ? 2016?01?16? 02:45, Hieu Hoang ??:
>>>>>>>>>>>>>>>>>> > could you make your model files
>>>>>>>>>>>>>>>>>> available for
>>>>>>>>>>>>>>>>>> download so I
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>> > replicate this problem.
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> > it seems like you're using a feature
>>>>>>>>>>>>>>>>>> function with
>>>>>>>>>>>>>>>>>> sparse
>>>>>>>>>>>>>>>>>> scores. I
>>>>>>>>>>>>>>>>>> > think the character '_' must be escaped.
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> > On 12/01/16 04:00, Dingyuan Wang wrote:
>>>>>>>>>>>>>>>>>> >> Hi all,
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >> I'm using EMS for doing experiments.
>>>>>>>>>>>>>>>>>> Every
>>>>>>>>>>>>>>>>>> time the
>>>>>>>>>>>>>>>>>> kbmira
>>>>>>>>>>>>>>>>>> died with
>>>>>>>>>>>>>>>>>> >> SIGABRT when turning on one direction,
>>>>>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>>>> tuning
>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>> opposite
>>>>>>>>>>>>>>>>>> >> direction (same config and test set) was
>>>>>>>>>>>>>>>>>> successful.
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >> The mert.log (stderr) shows follows:
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >> kbmira with c=0.01 decay=0.999
>>>>>>>>>>>>>>>>>> no_shuffle=0
>>>>>>>>>>>>>>>>>> >> Initialising random seed from system
>>>>>>>>>>>>>>>>>> clock
>>>>>>>>>>>>>>>>>> >> Found 15323 initial sparse features
>>>>>>>>>>>>>>>>>> >> ....terminate called after throwing an
>>>>>>>>>>>>>>>>>> instance of
>>>>>>>>>>>>>>>>>> >> 'MosesTuning::FileFormatException'
>>>>>>>>>>>>>>>>>> >> what(): Error in line "-4.51933 0 0
>>>>>>>>>>>>>>>>>> -6.09733
>>>>>>>>>>>>>>>>>> 0 0 0
>>>>>>>>>>>>>>>>>> -121.556 2
>>>>>>>>>>>>>>>>>> -20 12
>>>>>>>>>>>>>>>>>> >> -31.6201 -38.5211 -26.5112 -60.6166
>>>>>>>>>>>>>>>>>> WT_?~?=2
>>>>>>>>>>>>>>>>>> WT_?~?=1
>>>>>>>>>>>>>>>>>> PL_s1=4
>>>>>>>>>>>>>>>>>> >> PL_s3=1 PL_3,3=1 PL_2,2=3 PL_1,2=1
>>>>>>>>>>>>>>>>>> PL_2,1=3
>>>>>>>>>>>>>>>>>> PL_t1=6
>>>>>>>>>>>>>>>>>> PL_t2=4
>>>>>>>>>>>>>>>>>> PL_t3=2
>>>>>>>>>>>>>>>>>> >> PL_2,3=1 PL_s2=7 PL_1,1=3 WT_?~??=1
>>>>>>>>>>>>>>>>>> WT_?~
>>>>>>>>>>>>>>>>>> ??=1
>>>>>>>>>>>>>>>>>> WT_?~
>>>>>>>>>>>>>>>>>> ?=1
>>>>>>>>>>>>>>>>>> WT_?~?
>>>>>>>>>>>>>>>>>> >> ?=1 WT_?~?=1 WT_?~?=2 WT_?~?=1 WT_
>>>>>>>>>>>>>>>>>> ?~?=1
>>>>>>>>>>>>>>>>>> WT_?~
>>>>>>>>>>>>>>>>>> ??=1
>>>>>>>>>>>>>>>>>> WT_
>>>>>>>>>>>>>>>>>> ?~?=1
>>>>>>>>>>>>>>>>>> >> WT_?~??=1 WT_?~?=1 WT_?~??=1
>>>>>>>>>>>>>>>>>> WT_?~
>>>>>>>>>>>>>>>>>> ??=1
>>>>>>>>>>>>>>>>>> WT_?~?
>>>>>>>>>>>>>>>>>> ?=1 WT_?~
>>>>>>>>>>>>>>>>>> >> ?=1 WT_?~??=1 " of run7.features.dat
>>>>>>>>>>>>>>>>>> >> Aborted
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >> I think since run7.scores.dat is
>>>>>>>>>>>>>>>>>> generated by
>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>> scripts, I
>>>>>>>>>>>>>>>>>> wouldn't
>>>>>>>>>>>>>>>>>> >> be responsible for making the bad
>>>>>>>>>>>>>>>>>> format. Last
>>>>>>>>>>>>>>>>>> time it
>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>> died, I
>>>>>>>>>>>>>>>>>> >> removed the likely offending line in
>>>>>>>>>>>>>>>>>> the test
>>>>>>>>>>>>>>>>>> set, but
>>>>>>>>>>>>>>>>>> this time
>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>> >> line appears.
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >> --
>>>>>>>>>>>>>>>>>> >> Dingyuan Wang
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> >> Moses-support mailing list
>>>>>>>>>>>>>>>>>> >> Moses-support@mit.edu
>>>>>>>>>>>>>>>>>> <mailto:Moses-support@mit.edu>
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Dingyuan Wang (gumblex)
>>>>>>>>>>>>>>>>>>
>>
>
>

--
Dingyuan Wang (gumblex)


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

Message: 2
Date: Wed, 20 Jan 2016 14:06:06 +0000
From: Barry Haddow <bhaddow@staffmail.ed.ac.uk>
Subject: [Moses-support] Job: Researcher in Statistical MT at the
University of Edinburgh
To: moses-support <moses-support@mit.edu>
Message-ID: <569F944E.2040009@staffmail.ed.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi

We are looking for a new researcher to join the statmt group in Edinburgh

Link to the advert:
https://www.vacancies.ed.ac.uk/pls/corehrrecruit/erq_jobspec_version_4.jobspec?p_id=035233

About the group:
http://www.statmt.org/ued/

cheers - Barry

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



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

Message: 3
Date: Wed, 20 Jan 2016 16:31:13 +0100
From: Matjaz Rihtar <matjaz@eunet.si>
Subject: Re: [Moses-support] mgiza signal 11 coredump
To: Moses SMT Support <moses-support@mit.edu>
Message-ID: <569FA841.70302@eunet.si>
Content-Type: text/plain; charset=utf-8

I've found the reason for this coredump: USER environment variable not set, bug already reported on Feb 2, 2015
https://github.com/moses-smt/mgiza/issues/4
Said to be fixed in the next few days ;-), which can now be easily done if my pull request #7 on github:moses-smt/mgiza is merged into master.

Best regards,
Matjaz



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

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


End of Moses-support Digest, Vol 111, Issue 64
**********************************************

Tweet