Moses-support Digest, Vol 111, Issue 24

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)
2. Re: Error when running moses server with sample code
(Lane Schwartz)
3. Re: Error when running moses server with sample code
(Lane Schwartz)


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

Message: 1
Date: Tue, 12 Jan 2016 10:10:47 +0000
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] Which symal?
To: Ergun Bicici <ergun.bicici@dfki.de>, moses-support
<moses-support@mit.edu>
Message-ID: <5694D127.3020106@gmail.com>
Content-Type: text/plain; charset="utf-8"

You shouldn't assume that.

symal predates Moses, I'm not sure who wrote it. It may be that the
author allowed it to be dual licensed.

The license for Moses is clear and has not changed since it started -
LGPL 2.1. The license for mgiza and GIZA++ is also looks clear - GPL 2

On 12/01/16 10:01, Ergun Bicici wrote:
>
> So, you can sublicense Moses (LGPL) but not mgiza (GPL):
> http://choosealicense.com/licenses/
> ??
> ?Which I guess may m?ean something like that you can re-license a
> modified version of Moses without symal but not with symal. ?In other
> words, to license a modified version of? Moses with your own terms,
> you need to take out symal from mgiza or any GPL or code having some
> more restrictive license and keep symal that comes with Moses.
>
>
> /Best Regards,/
> Ergun
>
> Ergun Bi?ici
> DFKI Projektb?ro Berlin
>
>
> On Tue, Jan 12, 2016 at 3:09 AM, Tom Hoar
> <tahoar@precisiontranslationtools.com
> <mailto:tahoar@precisiontranslationtools.com>> wrote:
>
> Don't have experience with EMS, but our Slate packages (Linux &
> Windows)
> include both MGIZA and Moses binaries the same `$bin` folder and
> we set
> the train-model.perl --external-bin-dir=$bin value and all other
> binary
> path references to that one folder. The symal binary is the only
> conflict file name. So, we use the one from Moses. From what we could
> tell, they are essentially the same source but the Moses copy seems to
> have been maintained/updated more recently. Also be careful
> because the
> two versions are published under different open source licenses.
>
> I don't know if this approach will work with EMS, but it is a simple
> solution.
>
> Tom
>
>
> On 1/12/2016 3:56 AM, moses-support-request@mit.edu
> <mailto:moses-support-request@mit.edu> wrote:
> > Date: Mon, 11 Jan 2016 20:56:49 +0000
> > From: Hieu Hoang<hieuhoang@gmail.com <mailto:hieuhoang@gmail.com>>
> > Subject: Re: [Moses-support] Which symal?
> > To: Ergun Bicici<ergun.bicici@dfki.de <mailto:ergun.bicici@dfki.de>>
> > Cc: moses-support<moses-support@mit.edu
> <mailto:moses-support@mit.edu>>
> >
> > 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.
>
> _______________________________________________
> 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
> http://mailman.mit.edu/mailman/listinfo/moses-support

--
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/20160112/1cc45e05/attachment-0001.html

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

Message: 2
Date: Tue, 12 Jan 2016 09:47:49 -0600
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] Error when running moses server with
sample code
To: Barry Haddow <bhaddow@staffmail.ed.ac.uk>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CABv3vZ=tMvYfV5rJw5iFVwG6B+rvYs8FQsQcCLwCrhTjox=3=Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I compiled with variant=debug. What else do I need to do to get a stack
trace?

On Tue, Jan 12, 2016 at 3:16 AM, Barry Haddow <bhaddow@staffmail.ed.ac.uk>
wrote:

> Hi Lane
>
> Can you get a stack trace to see which line the message is coming from?
> That error message is repeated in a few files.
>
> From looking at the code, I'd guess that the OutputFactorOrder is not
> being initialised correctly. Possibly due to the refactoring of the config
> code. Does your example work with an earlier version of Moses?
>
> cheers - Barry
>
>
> On 11/01/16 21:43, Lane Schwartz wrote:
>
> Hi,
>
> I'm trying out mosesserver for the first time. I have a config file for
> fr-en that uses a smallish TM and LM, that work fine when run with Moses.
> When I try running the same config using mosesserver, and then use the
> sample Perl or Python code in contrib/server, mosesserver dies with the
> following error:
>
> Defined parameters (per moses.ini or switch):
>> config: moses.tuned.ini.2.probing.noLexRO
>> cube-pruning-pop-limit: 400
>> distortion-limit: 6
>> feature: UnknownWordPenalty WordPenalty PhrasePenalty ProbingPT
>> name=TranslationModel0 num-features=4
>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>> table-limit=20 Distortion KENLM lazyken=1 name=LM0 factor=0
>> path=europarl.kenlm order=5
>> input-factors: 0
>> mapping: 0 T 0
>> max-phrase-length: 20
>> n-best-list: nbest.txt 111
>> output-hypo-score: 1
>> search-algorithm: 0
>> server:
>> threads: 1
>> weight: Distortion0= 0.0222366 LM0= 0.0834208 WordPenalty0= -0.0654626
>> PhrasePenalty0= 0.0220686 TranslationModel0= 0.0520176 0.0415173 0.124293
>> 0.027126 UnknownWordPenalty0= 1
>>
>> line=UnknownWordPenalty
>> FeatureFunction: UnknownWordPenalty0 start: 0 end: 0
>> line=WordPenalty
>> FeatureFunction: WordPenalty0 start: 1 end: 1
>> line=PhrasePenalty
>> FeatureFunction: PhrasePenalty0 start: 2 end: 2
>> line=ProbingPT name=TranslationModel0 num-features=4
>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>> table-limit=20
>> FeatureFunction: TranslationModel0 start: 3 end: 6
>> line=Distortion
>> FeatureFunction: Distortion0 start: 7 end: 7
>> line=KENLM lazyken=1 name=LM0 factor=0 path=europarl.kenlm order=5
>> FeatureFunction: LM0 start: 8 end: 8
>> Loading UnknownWordPenalty0
>> Loading WordPenalty0
>> Loading PhrasePenalty0
>> Loading Distortion0
>> Loading LM0
>> Loading TranslationModel0
>> Initialized successfully!
>>
>> RUN SERVER at pid 1733327039
>> [moses/server/Server.cpp:49] Listening on port 8080
>> [moses/server/TranslationRequest.cpp:281] Input: il a souhait? que la
>> pr?sidence trace ? nice le chemin pour l' avenir .
>> Translating: il a souhait? que la pr?sidence trace ? nice le chemin pour
>> l' avenir .
>>
>> Line 0: Collecting options took 0.038 seconds at moses/Manager.cpp Line
>> 141
>> Line 0: Search took 0.674 seconds
>> terminate called after throwing an instance of 'util::Exception'
>> what(): No factor 1 at position 0
>
>
> Any idea what's going on here? I'm using a basic single-factor model, so I
> don't get why it would be complaining about factors. I'm using the latest
> moses from git.
>
> Thanks,
> Lane
>
>
>
> _______________________________________________
> Moses-support mailing listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>


--
When a place gets crowded enough to require ID's, social collapse is not
far away. It is time to go elsewhere. The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160112/035a473b/attachment-0001.html

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

Message: 3
Date: Tue, 12 Jan 2016 09:59:22 -0600
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] Error when running moses server with
sample code
To: Barry Haddow <bhaddow@staffmail.ed.ac.uk>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CABv3vZkb1L4_hUOw32QM=426zz2VFLMUQzVHejSLZRxCeDg1tw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Never mind. I figured out how.

(gdb) bt
> #0 0x00007ffff5d905e9 in raise () from /lib64/libc.so.6
> #1 0x00007ffff5d91cf8 in abort () from /lib64/libc.so.6
> #2 0x00007ffff68b09b5 in __gnu_cxx::__verbose_terminate_handler() () from
> /lib64/libstdc++.so.6
> #3 0x00007ffff68ae926 in ?? () from /lib64/libstdc++.so.6
> #4 0x00007ffff68ae953 in std::terminate() () from /lib64/libstdc++.so.6
> #5 0x00007ffff68aeb73 in __cxa_throw () from /lib64/libstdc++.so.6
> #6 0x000000000073a695 in Moses::Manager::OutputSurface
> (this=0x7ffe4e9e6980, out=..., edge=..., recursive=false) at
> moses/Manager.cpp:1726
> Python Exception <type 'exceptions.IndexError'> list index out of range:
> #7 0x000000000088c6f3 in MosesServer::TranslationRequest::pack_hypothesis
> (this=0x1848b40, manager=..., edges=std::vector of length 13, capacity 16 =
> {...}, key="text", dest=std::map with 0 elements) at
> moses/server/TranslationRequest.cpp:358
> Python Exception <type 'exceptions.IndexError'> list index out of range:
> #8 0x000000000088d02c in MosesServer::TranslationRequest::pack_hypothesis
> (this=0x1848b40, manager=..., h=0x0, key="text", dest=std::map with 0
> elements) at moses/server/TranslationRequest.cpp:393
> #9 0x000000000088d128 in
> MosesServer::TranslationRequest::run_phrase_decoder (this=0x1848b40) at
> moses/server/TranslationRequest.cpp:403
> #10 0x0000000000888483 in MosesServer::TranslationRequest::Run
> (this=0x1848b40) at moses/server/TranslationRequest.cpp:70
> #11 0x00000000006d4b9e in Moses::ThreadPool::Execute (this=0x18ae028) at
> moses/ThreadPool.cpp:58
> #12 0x00000000006d7071 in boost::_mfi::mf0<void,
> Moses::ThreadPool>::operator() (this=0x189a398, p=0x18ae028) at
> /usr/local/include/boost/bind/mem_fn_template.hpp:49
> #13 0x00000000006d6fd4 in
> boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
> >::operator()<boost::_mfi::mf0<void, Moses::ThreadPool>, boost::_bi::list0>
> (this=0x189a3a8, f=..., a=...) at /usr/local/include/boost/bind/bind.hpp:255
> #14 0x00000000006d6f83 in boost::_bi::bind_t<void, boost::_mfi::mf0<void,
> Moses::ThreadPool>, boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
> > >::operator() (this=0x189a398) at
> /usr/local/include/boost/bind/bind_template.hpp:20
> #15 0x00000000006d6f48 in
> boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void,
> Moses::ThreadPool>, boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
> > > >::run (this=0x189a1e0) at
> /usr/local/include/boost/thread/detail/thread.hpp:116
> #16 0x000000000098d78f in thread_proxy ()
> #17 0x00007ffff6123df3 in start_thread () from /lib64/libpthread.so.0
> #18 0x00007ffff5e511ed in clone () from /lib64/libc.so.


The error occurs when the python client sets "report-all-factors":"true".



On Tue, Jan 12, 2016 at 9:47 AM, Lane Schwartz <dowobeha@gmail.com> wrote:

> I compiled with variant=debug. What else do I need to do to get a stack
> trace?
>
> On Tue, Jan 12, 2016 at 3:16 AM, Barry Haddow <bhaddow@staffmail.ed.ac.uk>
> wrote:
>
>> Hi Lane
>>
>> Can you get a stack trace to see which line the message is coming from?
>> That error message is repeated in a few files.
>>
>> From looking at the code, I'd guess that the OutputFactorOrder is not
>> being initialised correctly. Possibly due to the refactoring of the config
>> code. Does your example work with an earlier version of Moses?
>>
>> cheers - Barry
>>
>>
>> On 11/01/16 21:43, Lane Schwartz wrote:
>>
>> Hi,
>>
>> I'm trying out mosesserver for the first time. I have a config file for
>> fr-en that uses a smallish TM and LM, that work fine when run with Moses.
>> When I try running the same config using mosesserver, and then use the
>> sample Perl or Python code in contrib/server, mosesserver dies with the
>> following error:
>>
>> Defined parameters (per moses.ini or switch):
>>> config: moses.tuned.ini.2.probing.noLexRO
>>> cube-pruning-pop-limit: 400
>>> distortion-limit: 6
>>> feature: UnknownWordPenalty WordPenalty PhrasePenalty ProbingPT
>>> name=TranslationModel0 num-features=4
>>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>>> table-limit=20 Distortion KENLM lazyken=1 name=LM0 factor=0
>>> path=europarl.kenlm order=5
>>> input-factors: 0
>>> mapping: 0 T 0
>>> max-phrase-length: 20
>>> n-best-list: nbest.txt 111
>>> output-hypo-score: 1
>>> search-algorithm: 0
>>> server:
>>> threads: 1
>>> weight: Distortion0= 0.0222366 LM0= 0.0834208 WordPenalty0= -0.0654626
>>> PhrasePenalty0= 0.0220686 TranslationModel0= 0.0520176 0.0415173 0.124293
>>> 0.027126 UnknownWordPenalty0= 1
>>>
>>> line=UnknownWordPenalty
>>> FeatureFunction: UnknownWordPenalty0 start: 0 end: 0
>>> line=WordPenalty
>>> FeatureFunction: WordPenalty0 start: 1 end: 1
>>> line=PhrasePenalty
>>> FeatureFunction: PhrasePenalty0 start: 2 end: 2
>>> line=ProbingPT name=TranslationModel0 num-features=4
>>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>>> table-limit=20
>>> FeatureFunction: TranslationModel0 start: 3 end: 6
>>> line=Distortion
>>> FeatureFunction: Distortion0 start: 7 end: 7
>>> line=KENLM lazyken=1 name=LM0 factor=0 path=europarl.kenlm order=5
>>> FeatureFunction: LM0 start: 8 end: 8
>>> Loading UnknownWordPenalty0
>>> Loading WordPenalty0
>>> Loading PhrasePenalty0
>>> Loading Distortion0
>>> Loading LM0
>>> Loading TranslationModel0
>>> Initialized successfully!
>>>
>>> RUN SERVER at pid 1733327039
>>> [moses/server/Server.cpp:49] Listening on port 8080
>>> [moses/server/TranslationRequest.cpp:281] Input: il a souhait? que la
>>> pr?sidence trace ? nice le chemin pour l' avenir .
>>> Translating: il a souhait? que la pr?sidence trace ? nice le chemin pour
>>> l' avenir .
>>>
>>> Line 0: Collecting options took 0.038 seconds at moses/Manager.cpp Line
>>> 141
>>> Line 0: Search took 0.674 seconds
>>> terminate called after throwing an instance of 'util::Exception'
>>> what(): No factor 1 at position 0
>>
>>
>> Any idea what's going on here? I'm using a basic single-factor model, so
>> I don't get why it would be complaining about factors. I'm using the latest
>> moses from git.
>>
>> Thanks,
>> Lane
>>
>>
>>
>> _______________________________________________
>> Moses-support mailing listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>
>
> --
> When a place gets crowded enough to require ID's, social collapse is not
> far away. It is time to go elsewhere. The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>



--
When a place gets crowded enough to require ID's, social collapse is not
far away. It is time to go elsewhere. The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160112/5f16062d/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 24
**********************************************

Related Posts :

0 Response to "Moses-support Digest, Vol 111, Issue 24"

Post a Comment