Moses has supported IRSTLM in training and decoding since the beginning and we've always tried to maintain the link.
There's occasional issues with incompatible versions 'cos they're an independent project with their own timeline. But these are sorted out pdq. The threading issue is a IRSTLM-specific problem 'cos I think they have a non-threadsafe cache Hieu Hoang Researcher New York University, Abu Dhabi http://www.hoang.co.uk/hieu On 6 May 2015 at 11:58, Tomas Fulajtar <toma...@moravia.com> wrote: > Dear Hieu, > > > > That sounds great – then it’s finally a time for upgrade J > > > > As Barry mentioned – could you briefly share with us where moses stands > with IRTSLM? > > > > Thanks, > > > > > > Tomas > > > > *From:* Hieu Hoang [mailto:hieuho...@gmail.com] > *Sent:* Wednesday, May 6, 2015 9:51 AM > *To:* Tomas Fulajtar > *Cc:* Barry Haddow; moses-support > > *Subject:* Re: [Moses-support] Fwd: Fwd: Server development > > > > i'm not sure about v 2.1.1 but v 3.0 should have no problems using > threads. (Apart from when using it with IRSTLM, but that's another issue) > > > Hieu Hoang > Researcher > > New York University, Abu Dhabi > > http://www.hoang.co.uk/hieu > > > > On 6 May 2015 at 11:38, Tomas Fulajtar <toma...@moravia.com> wrote: > > Hi Barry, > > > Thanks for explanation – I was referring to “[Moses-support] mosesserver > parallelization issue > <https://www.mail-archive.com/search?l=moses-support@mit.edu&q=subject:%22%5C%5BMoses%5C-support%5C%5D+mosesserver+parallelization+issue%22&o=newest>” > thread in April 2014. Do you thing the thread pool would be also the > solution for this issue reported on 2.1.1 branch.? Thanks, > > > > Tomas > > > > > > *From:* Barry Haddow [mailto:bhad...@inf.ed.ac.uk] > *Sent:* Tuesday, May 5, 2015 9:27 PM > *To:* Hieu Hoang; moses-support > *Subject:* Re: [Moses-support] Fwd: Fwd: Server development > > > > HI Tomas > > There were some issues in v2 with the way that caching was done in the > binarised phrase table. It used a cache per thread, and mosesserver used a > thread per request, so caching was effectively broken in the server. Since > last Autumn, mosesserver uses a thread pool ... and the binarised phrase > table is gone now anyway, > > cheers - Barry > > > > On 05/05/15 18:27, Hieu Hoang wrote: > > What limitations are you referring to? > > ---------- Forwarded message ---------- > From: "Ulrich Germann" <ulrich.germ...@gmail.com> > Date: 5 May 2015 19:49 > Subject: [Moses-support] Fwd: Server development > To: "moses-support@mit.edu" <moses-support@mit.edu> > Cc: > > This response was meant to go to moses-support as well Tomas. > > > > ---------- Forwarded message ---------- > From: *Tomas Fulajtar* <toma...@moravia.com> > Date: Fri, Apr 3, 2015 at 5:03 PM > Subject: RE: [Moses-support] Server development > To: "ugerm...@inf.ed.ac.uk" <ugerm...@inf.ed.ac.uk> > > Hi Ulrich, > > > > Thanks for the thorough explanation - the idea of merging the server code > back to moses is great. > > Apart from this (and I know is is a huge workload), were there any changes > in the thread support? I know this part had some limitations – as > discussed on the forum. > > > > Kind regards, > > Tomas > > > > > > *From:* Ulrich Germann [mailto:ulrich.germ...@gmail.com] > *Sent:* Thursday, April 2, 2015 12:57 AM > *To:* Tomas Fulajtar > *Subject:* Re: [Moses-support] Server development > > > > Hi Tomas, > > > > the plan is to fold server capabilities into the main moses executable. In > fact, that has already happened (in the sense that you can run the main > moses executable in server mode), but functional equivalence with the old > code has not been tested. > > > > There are currently no server tests included in the regression tests, so I > left the old code mostly intact (adjusting only for changes in the API of > functions called) for legacy reasons, but adding new functionality to > mosesserver is extremely strongly DIScouraged. > > > > Supplying regression tests for server functionality, on the other hand, is > equally strongly ENcouraged. In a nutshell, what you get back from calling > mosesserver and moses --server should be identical. > > > > The long-term plan is to offer through RPC calls (almost) everything that > moses offers in batch mode (i.e., send search and output parameters through > json/RCP calls and have them noticed and respected). Notice the "long-term" > there. > > > > So mosesserver is on its way out, and moses --server-port=<port> --server > will replace the old call to mosesserver. > > > > Best regards - Uli > > > > On Wed, Apr 1, 2015 at 9:48 AM, Tomas Fulajtar <toma...@moravia.com> > wrote: > > Dear all, > > > > I have spotted there were numerous commits in the server side development > - could the developers share the news/goals with the forum? I think it > might be interesting for more users – especially those out of core team. > > > > Thank you, > > > > *Tomáš Fulajtár* | Researcher > *T:* +420-545-552-340 > toma...@moravia.com | moravia.com <http://www.moravia.com/> | *Skype:* > tomasfulajtar > > > > > _______________________________________________ > Moses-support mailing list > Moses-support@mit.edu > http://mailman.mit.edu/mailman/listinfo/moses-support > > > > > > -- > > Ulrich Germann > Senior Researcher > > School of Informatics > > University of Edinburgh > > > > > > -- > > Ulrich Germann > Senior Researcher > > School of Informatics > > University of Edinburgh > > > _______________________________________________ > Moses-support mailing list > 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 > > > > >
_______________________________________________ Moses-support mailing list Moses-support@mit.edu http://mailman.mit.edu/mailman/listinfo/moses-support
