Moses-support Digest, Vol 83, Issue 39

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: compile error with LDHT in randlm (Hieu Hoang)
2. Re: compile error with LDHT in randlm (Miles Osborne)
3. Re: compile error with LDHT in randlm (Lane Schwartz)
4. Re: compile error with LDHT in randlm (Miles Osborne)


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

Message: 1
Date: Wed, 25 Sep 2013 15:22:31 +0100
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] compile error with LDHT in randlm
To: moses-support@mit.edu, Hoai-Thu Vuong <thuvh87@gmail.com>, Oliver
Wilson <oliver.wilson87@gmail.com>, Miles Osborne <miles@inf.ed.ac.uk>
Message-ID: <5242F1A7.5070203@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I'm not sure how to compile LDHT but when i compiled randlm from svn, i
had to change 2 minor things to get it to compile on my mac:
1. src/RandLM/Makefile.am: boost_thread --> boost_thread-mt
2. autogen.sh: libtoolize --> glibtoolize

Also, the distributed LM was supported in Moses v1. However, it has been
deleted from the current Moses in the git repository. I will try and
re-add it if a multi-pass, asynchronous decoding framework can be
created. If you're interested in doing this, I would be very glad to
help you

On 24/09/2013 11:51, Hoai-Thu Vuong wrote:
>
> Hello
>
> I build LDHT in randlm and have got some errors, look like
>
> MurmurHash3.cpp:81:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp:68:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp:60:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp:55:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp: In function 'void MurmurHash3_x86_32(const void*,
> int, uint32_t, void*)':
> MurmurHash3.cpp:55:23: error: inlining failed in call to always_inline
> 'uint32_t getblock(const uint32_t*, int)': function body can be
> overwritten at link time
>
>
> I attach full error log here. My compiler is g++ version 4.7, OS is
> Ubuntu server 64bit 13.04, I clean install then install require
> package such as git, build essential, libtool, autoconf, google sparse
> hash, boost thread. With same source code I compile successful with
> g++ version 4.6, OS is ubuntu 64bit 12.04.
>
> I google solution to fix, and one guy recommend me change line (in
> MurmurHash3.cpp):
>
> #define FORCE_INLINE __attribute__((always_inline))
>
> to
>
> #define FORCE_INLINE inline __attribute__((always_inline))
>
> do this, I pass this error, however, I receive another error
> ::close(m_sd) not found in deconstructor of ~TransportTCP()
>
>
>
>
> --
> Thu.
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20130925/f68ab07c/attachment-0001.htm

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

Message: 2
Date: Wed, 25 Sep 2013 10:24:10 -0400
From: Miles Osborne <miles@inf.ed.ac.uk>
Subject: Re: [Moses-support] compile error with LDHT in randlm
To: Hieu Hoang <hieuhoang@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Oliver Wilson
<oliver.wilson87@gmail.com>, Hoai-Thu Vuong <thuvh87@gmail.com>
Message-ID:
<CAPRfTYqwkhfUtLK2cEkKTEv63xJ0fPZrF+iYriqdaun3gWMyLQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

If I recall the decoder was modified to allow batching of LM requests.

Miles

On 25 September 2013 10:22, Hieu Hoang <hieuhoang@gmail.com> wrote:
> I'm not sure how to compile LDHT but when i compiled randlm from svn, i had
> to change 2 minor things to get it to compile on my mac:
> 1. src/RandLM/Makefile.am: boost_thread --> boost_thread-mt
> 2. autogen.sh: libtoolize --> glibtoolize
>
> Also, the distributed LM was supported in Moses v1. However, it has been
> deleted from the current Moses in the git repository. I will try and re-add
> it if a multi-pass, asynchronous decoding framework can be created. If
> you're interested in doing this, I would be very glad to help you
>
> On 24/09/2013 11:51, Hoai-Thu Vuong wrote:
>
>
> Hello
>
> I build LDHT in randlm and have got some errors, look like
>
> MurmurHash3.cpp:81:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp:68:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp:60:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp:55:23: warning: always_inline function might not be
> inlinable [-Wattributes]
> MurmurHash3.cpp: In function 'void MurmurHash3_x86_32(const void*, int,
> uint32_t, void*)':
> MurmurHash3.cpp:55:23: error: inlining failed in call to always_inline
> 'uint32_t getblock(const uint32_t*, int)': function body can be overwritten
> at link time
>
>
> I attach full error log here. My compiler is g++ version 4.7, OS is Ubuntu
> server 64bit 13.04, I clean install then install require package such as
> git, build essential, libtool, autoconf, google sparse hash, boost thread.
> With same source code I compile successful with g++ version 4.6, OS is
> ubuntu 64bit 12.04.
>
> I google solution to fix, and one guy recommend me change line (in
> MurmurHash3.cpp):
>
> #define FORCE_INLINE __attribute__((always_inline))
>
> to
>
> #define FORCE_INLINE inline __attribute__((always_inline))
>
> do this, I pass this error, however, I receive another error ::close(m_sd)
> not found in deconstructor of ~TransportTCP()
>
>
>
>
> --
> Thu.
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>



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


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

Message: 3
Date: Wed, 25 Sep 2013 10:34:08 -0400
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] compile error with LDHT in randlm
To: Miles Osborne <miles@inf.ed.ac.uk>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Oliver Wilson
<oliver.wilson87@gmail.com>, Hoai-Thu Vuong <thuvh87@gmail.com>
Message-ID:
<CABv3vZnxhJk42LnM92mOexcuzzf02cWVkSG-2OBzF_Wtkd4o1A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Miles,

I heard that rumor as well. If anyone could point me to any
documentation that describes how to do this, I would be interested in
trying out this functionality.

Cheers,
Lane

On Wed, Sep 25, 2013 at 10:24 AM, Miles Osborne <miles@inf.ed.ac.uk> wrote:
> If I recall the decoder was modified to allow batching of LM requests.
>
> Miles
>
> On 25 September 2013 10:22, Hieu Hoang <hieuhoang@gmail.com> wrote:
>> I'm not sure how to compile LDHT but when i compiled randlm from svn, i had
>> to change 2 minor things to get it to compile on my mac:
>> 1. src/RandLM/Makefile.am: boost_thread --> boost_thread-mt
>> 2. autogen.sh: libtoolize --> glibtoolize
>>
>> Also, the distributed LM was supported in Moses v1. However, it has been
>> deleted from the current Moses in the git repository. I will try and re-add
>> it if a multi-pass, asynchronous decoding framework can be created. If
>> you're interested in doing this, I would be very glad to help you
>>
>> On 24/09/2013 11:51, Hoai-Thu Vuong wrote:
>>
>>
>> Hello
>>
>> I build LDHT in randlm and have got some errors, look like
>>
>> MurmurHash3.cpp:81:23: warning: always_inline function might not be
>> inlinable [-Wattributes]
>> MurmurHash3.cpp:68:23: warning: always_inline function might not be
>> inlinable [-Wattributes]
>> MurmurHash3.cpp:60:23: warning: always_inline function might not be
>> inlinable [-Wattributes]
>> MurmurHash3.cpp:55:23: warning: always_inline function might not be
>> inlinable [-Wattributes]
>> MurmurHash3.cpp: In function 'void MurmurHash3_x86_32(const void*, int,
>> uint32_t, void*)':
>> MurmurHash3.cpp:55:23: error: inlining failed in call to always_inline
>> 'uint32_t getblock(const uint32_t*, int)': function body can be overwritten
>> at link time
>>
>>
>> I attach full error log here. My compiler is g++ version 4.7, OS is Ubuntu
>> server 64bit 13.04, I clean install then install require package such as
>> git, build essential, libtool, autoconf, google sparse hash, boost thread.
>> With same source code I compile successful with g++ version 4.6, OS is
>> ubuntu 64bit 12.04.
>>
>> I google solution to fix, and one guy recommend me change line (in
>> MurmurHash3.cpp):
>>
>> #define FORCE_INLINE __attribute__((always_inline))
>>
>> to
>>
>> #define FORCE_INLINE inline __attribute__((always_inline))
>>
>> do this, I pass this error, however, I receive another error ::close(m_sd)
>> not found in deconstructor of ~TransportTCP()
>>
>>
>>
>>
>> --
>> Thu.
>>
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support



--
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"


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

Message: 4
Date: Wed, 25 Sep 2013 11:10:21 -0400
From: Miles Osborne <miles@inf.ed.ac.uk>
Subject: Re: [Moses-support] compile error with LDHT in randlm
To: Lane Schwartz <dowobeha@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Oliver Wilson
<oliver.wilson87@gmail.com>, Hoai-Thu Vuong <thuvh87@gmail.com>
Message-ID:
<CAPRfTYohMTRs05UHOwotVUeowbuMVrUmB6yvMpUDPUziOsV2fA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

have a look at:

SearchNormalBatch.h

in the source

Miles

On 25 September 2013 10:34, Lane Schwartz <dowobeha@gmail.com> wrote:
> Miles,
>
> I heard that rumor as well. If anyone could point me to any
> documentation that describes how to do this, I would be interested in
> trying out this functionality.
>
> Cheers,
> Lane
>
> On Wed, Sep 25, 2013 at 10:24 AM, Miles Osborne <miles@inf.ed.ac.uk> wrote:
>> If I recall the decoder was modified to allow batching of LM requests.
>>
>> Miles
>>
>> On 25 September 2013 10:22, Hieu Hoang <hieuhoang@gmail.com> wrote:
>>> I'm not sure how to compile LDHT but when i compiled randlm from svn, i had
>>> to change 2 minor things to get it to compile on my mac:
>>> 1. src/RandLM/Makefile.am: boost_thread --> boost_thread-mt
>>> 2. autogen.sh: libtoolize --> glibtoolize
>>>
>>> Also, the distributed LM was supported in Moses v1. However, it has been
>>> deleted from the current Moses in the git repository. I will try and re-add
>>> it if a multi-pass, asynchronous decoding framework can be created. If
>>> you're interested in doing this, I would be very glad to help you
>>>
>>> On 24/09/2013 11:51, Hoai-Thu Vuong wrote:
>>>
>>>
>>> Hello
>>>
>>> I build LDHT in randlm and have got some errors, look like
>>>
>>> MurmurHash3.cpp:81:23: warning: always_inline function might not be
>>> inlinable [-Wattributes]
>>> MurmurHash3.cpp:68:23: warning: always_inline function might not be
>>> inlinable [-Wattributes]
>>> MurmurHash3.cpp:60:23: warning: always_inline function might not be
>>> inlinable [-Wattributes]
>>> MurmurHash3.cpp:55:23: warning: always_inline function might not be
>>> inlinable [-Wattributes]
>>> MurmurHash3.cpp: In function 'void MurmurHash3_x86_32(const void*, int,
>>> uint32_t, void*)':
>>> MurmurHash3.cpp:55:23: error: inlining failed in call to always_inline
>>> 'uint32_t getblock(const uint32_t*, int)': function body can be overwritten
>>> at link time
>>>
>>>
>>> I attach full error log here. My compiler is g++ version 4.7, OS is Ubuntu
>>> server 64bit 13.04, I clean install then install require package such as
>>> git, build essential, libtool, autoconf, google sparse hash, boost thread.
>>> With same source code I compile successful with g++ version 4.6, OS is
>>> ubuntu 64bit 12.04.
>>>
>>> I google solution to fix, and one guy recommend me change line (in
>>> MurmurHash3.cpp):
>>>
>>> #define FORCE_INLINE __attribute__((always_inline))
>>>
>>> to
>>>
>>> #define FORCE_INLINE inline __attribute__((always_inline))
>>>
>>> do this, I pass this error, however, I receive another error ::close(m_sd)
>>> not found in deconstructor of ~TransportTCP()
>>>
>>>
>>>
>>>
>>> --
>>> Thu.
>>>
>>>
>>> _______________________________________________
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>>>
>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
>
> --
> 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"



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


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

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


End of Moses-support Digest, Vol 83, Issue 39
*********************************************

Tweet