Vote: - The file name specified exists and is loaded. - There is no semantic meaning to the file name. - Marcin's header (there is a header, right?) indicates it's a minphr.
On 02/04/2015 08:47 AM, Tom Hoar wrote: > Sorry, I tested but the behavior wasn't really clear. Maybe it did load > the .minlexr first. Another test would be what happens if the raw > (uncompressed) text file is there without an extension. Either way, I > vote for declarations vice uncertainty. > > > On 02/04/2015 08:45 PM, Marcin Junczys-Dowmunt wrote: >> >> That's weird. It used to find the *.minlexr before the *.gz >> >> W dniu 2015-02-04 14:42, Tom Hoar napisał(a): >> >>> I tested more as it is now and the current work-around (delete the >>> extension) has limits. If the reordering-table.minlexr and >>> reordering-table.gz are both present in the referenced folder and >>> there's no extension in the config, moses loads the text .gz model. >>> If you remove the .gz file from the folder, moses finds/loads the >>> .minlexr file. This creates uncertainty and possibly problems for >>> some users. >>> >>> I think any/all of your solutions proposals will solve uncertainty. >>> Requiring a fixed extension is probably the easiest. Defining a >>> feature (ReorderingCompact or LexicalReorderingCompact) would make >>> lexical configuration management more like the PhraseDictionary & >>> PhraseDictionaryCompact. There's a lot to be said for consistency. >>> >>> Ultimately, I don't have a preference either way. Easy is sometimes >>> better :) For now, we'll use the work-around. >>> >>> >>> >>> On 02/04/2015 08:29 PM, Marcin Junczys-Dowmunt wrote: >>>> >>>> The problem is that Reordering models have a base class that manages >>>> and delegates loading. If I remember correctly there is some kind of >>>> preference hard coded, if something exists that has the minlexr >>>> suffix, take if before *.binphr and *.gz. Some time ago the compact >>>> phrase table would not work with the suffix, so this was at least >>>> consistent. That changed in the meantime and now we have this >>>> current mess. >>>> >>>> What would be the best solution? >>>> A) fix suffix handling, >>>> B) define a ReorderingCompact feature >>>> C) both >>>> >>>> W dniu 2015-02-04 14:18, Tom Hoar napisał(a): >>>> >>>> Hi, Marcin, >>>> >>>> 1) comment out the reordering model (both, feature and weights): >>>> works. Exception disappears. >>>> 2) Remove file extension ".minlexr" from path= reference: works. >>>> file loads and model works >>>> >>>> Additional test: >>>> 3) Remove file extension ".minphr" from compact phrase table's >>>> path= reference: works. >>>> >>>> Is it possible this exception has to do with the filename buffer >>>> vice algorithm? >>>> >>>> FYI, I'm using the build-in boost library from Ubuntu 14.04 >>>> libboost 1.54 >>>> apt-get install libboost-all-dev >>>> >>>> >>>> >>>> >>>> On 02/04/2015 07:04 PM, Marcin Junczys-Dowmunt wrote: >>>> >>>> Hi, >>>> >>>> urgh, I saw this sometimes, could you comment out the >>>> reordering model (both, feature and weights) and check if >>>> you still get that? If not, uncomment and try to remove the >>>> file suffix "minlexr" for the reordering model. If it still >>>> happens, update boost :) (someone had the same problem and >>>> updating boost fixed it miraculously, no idea why though) >>>> >>>> >>>> >>>> W dniu 2015-02-04 12:44, Tom Hoar napisał(a): >>>> >>>> Hi everyone, >>>> >>>> I just build the new R-3. I'm also in the middle of updating >>>> our environment. I had a problem preparing for mert-moses.pl. So, I cut >>>> back to basics... manual edits to the moses.ini file and command line. >>>> >>>> I attached the moses.ini file and its output log. I edited the >>>> moses.ini file to use compact phrase and reordering files, and KenLM with >>>> lazy option. It fails with "Exception: vector::_M_range_check". >>>> >>>> Is something wrong or missing with my edits? >>>> >>>> Also, more results addressed separately in another. >>>> >>>> >>>> _______________________________________________ >>>> Moses-support mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moses-support mailing list >>>> [email protected] >>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moses-support mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moses-support mailing list >>>> [email protected] >>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>> >>> >>> _______________________________________________ >>> Moses-support mailing list >>> [email protected] <mailto:[email protected]> >>> http://mailman.mit.edu/mailman/listinfo/moses-support >> >> >> >> > > > > _______________________________________________ > Moses-support mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/moses-support > _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
