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. [PATCH] BUGFIX: fix ScoreComponentCollection::ZeroAll(),
affecting MIRA (David Madl)
2. KenLM loading error (Lane Schwartz)
3. help (Parul gupta)
4. Re: [PATCH] BUGFIX: fix ScoreComponentCollection::ZeroAll(),
affecting MIRA (Hieu Hoang)
5. Mosesserver terminates with "girerr::error" (Mathias M?ller)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Mar 2016 20:00:08 +0100
From: David Madl <david@madlnet.net>
Subject: [Moses-support] [PATCH] BUGFIX: fix
ScoreComponentCollection::ZeroAll(), affecting MIRA
To: moses-support@mit.edu
Message-ID: <56F044B8.1000708@madlnet.net>
Content-Type: text/plain; charset=windows-1252
I observed a bug that ScoreComponentCollection core entries would retain
their score even after ZeroAll(). This may have affected the Moses
implementation of MIRA.
* std::valarray::resize(0) means "resize to 0" [1]
* subsequent accesses using operator[] result in undefined behavior [2]
FeatureVector::clear() is used by ScoreComponentCollection::ZeroAll(),
which in turn was used in these places:
./contrib/mira/Main.cpp:665: cumulativeWeights.ZeroAll();
./contrib/mira/Main.cpp:666: cumulativeWeightsBinary.ZeroAll();
./moses/Incremental.cpp:580: features.ZeroAll();
It seems to me that the Moses implementation of MIRA may have been affected?
[1] http://www.cplusplus.com/reference/valarray/valarray/resize/
[2] http://www.cplusplus.com/reference/valarray/valarray/operator%5B%5D/
---
moses/FeatureVector.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/moses/FeatureVector.cpp b/moses/FeatureVector.cpp
index 45a198c..f92bced 100644
--- a/moses/FeatureVector.cpp
+++ b/moses/FeatureVector.cpp
@@ -175,7 +175,7 @@ void FVector::resize(size_t newsize)
void FVector::clear()
{
- m_coreFeatures.resize(0);
+ m_coreFeatures.resize(m_coreFeatures.size(), 0);
m_features.clear();
}
-- 2.7.0
------------------------------
Message: 2
Date: Mon, 21 Mar 2016 18:34:58 -0500
From: Lane Schwartz <dowobeha@gmail.com>
Subject: [Moses-support] KenLM loading error
To: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CABv3vZ=78UtjtMkm+=L2CzwB2Hc-r-RfF7XFZ1F9aXSyBOQD1g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have a tiny LM that is giving me some problems. The LM wasn't trained
with any of the usual toolkits, so it may violate some assumptions that the
KenLM code in Moses makes.
I'm able to successfully query the LM using bin/query, but when I use the
LM within Moses I get the following error:
Reading dd_lm0.arpa
>
> ----5---10---15---20---25---30---35---40---45---50---55---60---65---70---75---80---85---90---95--100
>
> ****************************************************************************************************
> mosesserver: lm/model.cc:250: lm::FullScoreReturn
> lm::ngram::detail::GenericModel<Search,
> VocabularyT>::ScoreExceptBackoff(const WordIndex*, const WordIndex*,
> lm::WordIndex, lm::ngram::State&) const [with Search =
> lm::ngram::detail::HashedSearch<lm::ngram::BackoffValue>; VocabularyT =
> lm::ngram::ProbingVocabulary; lm::WordIndex = unsigned int]: Assertion
> `new_word < vocab_.Bound()' failed.
And here's the LM:
\data\
> ngram 1=22
> ngram 2=21
> \1-grams:
> 0 . -99
> 0 : -99
> 0 </s> -99
> -99 <s> -99
> -99 <unk>
> -4.30102999566 a -99
> -5.00005 affect
> 0 certain -99
> -4.30102999566 have -99
> -4.30102999566 impact -99
> 0 is -99
> -4.30102999566 negative -99
> -5.00005 negatively
> 0 new -99
> -4.30102999566 on -99
> 0 one -99
> 0 provisions -99
> 0 the -99
> 0 these -99
> 0 thing -99
> 0 turnout -99
> 0 will -99
> \2-grams:
> 0 . </s>
> 0 : these
> 0 <s> one
> -4.30102999566 a negative
> -5.00005 affect negatively
> 0 certain :
> -4.30102999566 have a
> -4.30102999566 impact on
> 0 is certain
> -4.30102999566 negative impact
> -5.00005 negatively the
> 0 new provisions
> -4.30102999566 on the
> 0 one thing
> 0 provisions will
> 0 the turnout
> 0 these new
> 0 thing is
> 0 turnout .
> -5.00005 will affect
> -4.30102999566 will have
> \end\
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160321/ef421437/attachment-0001.html
------------------------------
Message: 3
Date: Tue, 22 Mar 2016 12:13:00 +0530
From: Parul gupta <btpg71@gmail.com>
Subject: [Moses-support] help
To: moses-support@mit.edu
Message-ID:
<CAC9aE9C3q0LosQHotKKMzHZYOOow8ybb17hEQ=oVxGa9J6Wx+w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
NOT BUILDING MOSES SERVER!
Performing configuration checks
- Shared Boost : yes (cached)
- Static Boost : yes (cached)
...patience...
...patience...
...found 4563 targets...
SUCCESS
what does it mean ? is there anything wrong ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160322/43fe74ce/attachment-0001.html
------------------------------
Message: 4
Date: Tue, 22 Mar 2016 08:02:02 +0000
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] [PATCH] BUGFIX: fix
ScoreComponentCollection::ZeroAll(), affecting MIRA
To: David Madl <david@madlnet.net>, moses-support@mit.edu
Message-ID: <56F0FBFA.8090306@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
cheers. You should check it in yourself, or create a git pull request.
On 21/03/2016 19:00, David Madl wrote:
> I observed a bug that ScoreComponentCollection core entries would retain
> their score even after ZeroAll(). This may have affected the Moses
> implementation of MIRA.
>
> * std::valarray::resize(0) means "resize to 0" [1]
> * subsequent accesses using operator[] result in undefined behavior [2]
>
> FeatureVector::clear() is used by ScoreComponentCollection::ZeroAll(),
> which in turn was used in these places:
>
> ./contrib/mira/Main.cpp:665: cumulativeWeights.ZeroAll();
> ./contrib/mira/Main.cpp:666: cumulativeWeightsBinary.ZeroAll();
> ./moses/Incremental.cpp:580: features.ZeroAll();
>
> It seems to me that the Moses implementation of MIRA may have been affected?
>
> [1] http://www.cplusplus.com/reference/valarray/valarray/resize/
> [2] http://www.cplusplus.com/reference/valarray/valarray/operator%5B%5D/
> ---
> moses/FeatureVector.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/moses/FeatureVector.cpp b/moses/FeatureVector.cpp
> index 45a198c..f92bced 100644
> --- a/moses/FeatureVector.cpp
> +++ b/moses/FeatureVector.cpp
> @@ -175,7 +175,7 @@ void FVector::resize(size_t newsize)
> void FVector::clear()
> {
> - m_coreFeatures.resize(0);
> + m_coreFeatures.resize(m_coreFeatures.size(), 0);
> m_features.clear();
> }
> -- 2.7.0
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
------------------------------
Message: 5
Date: Tue, 22 Mar 2016 10:07:29 +0100
From: Mathias M?ller <mathias.mueller@uzh.ch>
Subject: [Moses-support] Mosesserver terminates with "girerr::error"
To: moses-support@mit.edu
Message-ID:
<CAF2XUm0Kn3qrGW3bEPW+vS2=EyxSNsO+FZ9atQb7Mg9j2vt+rg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear list
Since I got recent mosesdecoder code from Github (mid-February 2016) and
built a new version on our servers, I cannot run mosesserver anymore. The
non-server version of moses works fine.
The specific error I get when I request a translation from a running server
is:
*terminate called after throwing an instance of 'girerr::error' what():
Not string type. See type() method*
This happens even with the simplest of models, e.g. with the sample models
taken from:
http://www.statmt.org/moses/?n=Development.GetStarted
What does this error mean? Can anyone help me solve my problem?
I have attached the following files:
- commands.txt: the commands that lead to this error
- minimal-client.py: a few lines of Python code that request a
translation
- server.err: the server STDERR output
- python-output.txt: the output of minimal-client.py
If you need more information, I will gladly provide it.
Thanks for your help
Mathias
?
Mathias M?ller
BIN 2.B.04
Institute of Computational Linguistics
University of Zurich
+41 44 635 75 81
mathias.mueller@uzh.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160322/3e00b9f2/attachment.html
-------------- next part --------------
send: "POST /RPC2 HTTP/1.1\r\nHost: localhost:12345\r\nAccept-Encoding: gzip\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 327\r\n\r\n<?xml version='1.0'?>\n<methodCall>\n<methodName>translate</methodName>\n<params>\n<param>\n<value><struct>\n<member>\n<name>text</name>\n<value><string>das ist ein kleines haus</string></value>\n</member>\n<member>\n<name>word-align</name>\n<value><boolean>1</boolean></value>\n</member>\n</struct></value>\n</param>\n</params>\n</methodCall>\n"
reply: ''
Traceback (most recent call last):
File "minimal-client.py", line 6, in <module>
server.translate({"text": "das ist ein kleines haus", "word-align": True})
File "/usr/lib/python2.7/xmlrpclib.py", line 1233, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.7/xmlrpclib.py", line 1587, in __request
verbose=self.__verbose
File "/usr/lib/python2.7/xmlrpclib.py", line 1273, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/xmlrpclib.py", line 1301, in single_request
self.send_content(h, request_body)
File "/usr/lib/python2.7/xmlrpclib.py", line 1448, in send_content
connection.endheaders(request_body)
File "/usr/lib/python2.7/httplib.py", line 975, in endheaders
self._send_output(message_body)
File "/usr/lib/python2.7/httplib.py", line 835, in _send_output
self.send(msg)
File "/usr/lib/python2.7/httplib.py", line 797, in send
self.connect()
File "/usr/lib/python2.7/httplib.py", line 778, in connect
self.timeout, self.source_address)
File "/usr/lib/python2.7/socket.py", line 571, in create_connection
raise err
socket.error: [Errno 101] Network is unreachable
-------------- next part --------------
wget http://www.statmt.org/moses/download/sample-models.tgz
tar xzf sample-models.tgz
cd sample-models
mosesserver -f phrase-model/moses.ini --server-port 12345 2> server.err
python minimal-client.py
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.err
Type: application/octet-stream
Size: 2043 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/moses-support/attachments/20160322/3e00b9f2/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal-client.py
Type: text/x-python
Size: 179 bytes
Desc: not available
Url : http://mailman.mit.edu/mailman/private/moses-support/attachments/20160322/3e00b9f2/attachment.py
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 113, Issue 59
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 113, Issue 59"
Post a Comment