it seems like squishing everything into a bin directory is a good idea
for people who want to set their PATH variable to it.
it would be useful to do
moses --version
train-model.perl --version
and see when or which svn/git version it was built on. Didn't think it
was possible but you might know better
On 28/09/2011 16:55, Barry Haddow wrote:
> Hi
>
> So it looks like a date-stamped release folder is not popular. It would be
> possible to have a version stamp inserted into the binaries and scripts and
> have this read by ems - would this be useful?
>
> And would a 'make install' be of any use? It would mean that anyone who wanted
> a date-stamped release could make one with --prefix, and would help users to
> separate files needed at runtime from those needed at build time.
>
> If we do have a 'make install', should the scripts be squished into the bin
> directory, or have their directory structure preserved? If we go for the
> latter, then there would be the option of running them from a source directory
> too.
>
> cheers - Barry
>
>
>
> On Tuesday 27 September 2011 23:53:29 Raphael Payen wrote:
>> I like your idea of a VERSION.txt file. Maybe containing also the
>> configure line.
>>
>> By the way, there is already a make install which is configurable with
>> "configure --prefix=..." ; I dont understand if you want more than
>> this.
>>
>> Raphael
>>
>> 2011/9/27 Lane Schwartz<[email protected]>:
>>> I would like to see a true make install option. I don't care what the
>>> default location is, as long as it's configurable.
>>>
>>> At the least, I would prefer to see the binaries (and preferably
>>> scripts, too) installed to a bin directory within the moses dir
>>> instead of being spread throughout the source directories.
>>>
>>> I agree that it can be useful to know what version you're running on.
>>> But I don't think time stamped directories are the way to do it. I
>>> would propose that make install creates a VERSION.txt file that lists
>>> the svn version number, or some other version number.
>>>
>>> Lane
>>>
>>> On Tue, Sep 27, 2011 at 6:07 AM, Hieu Hoang<[email protected]> wrote:
>>>> I'd go with Ondrej and avoid any release procedure and run everything
>>>> in-situ. We can debug and commit scripts easier.
>>>>
>>>> Or have a very simple release that moves all executables and scripts
>>>> into a bin directory. If the user wants to move/rename, it's their
>>>> choice
>>>>
>>>> On 27 September 2011 16:30, Barry Haddow<[email protected]> wrote:
>>>>> Hi
>>>>>
>>>>> I think it's useful to have a date-stamped release directory, so that
>>>>> you can
>>>>> work on the code and have experiments running, but keep tracking of
>>>>> which version was used in which experiment. Many people at Edinburgh
>>>>> make a copy of
>>>>> the moses binary with the svn version number as suffix on the name.
>>>>>
>>>>> How about having a 'make install, which by default installs to a
>>>>> date-stamped
>>>>> directory, with the standard bin, lib etc. pattern, with all the
>>>>> scripts under
>>>>> bin? How big a change would that be?
>>>>>
>>>>> cheers - Barry
>>>>>
>>>>> On Friday 23 September 2011 08:46:06 Ondrej Bojar wrote:
>>>>>> Hi,
>>>>>>
>>>>>> mert-moses-new.pl is outdated, isn't it? There should be only
>>>>>> mert-moses.pl these days.
>>>>>>
>>>>>> The 'scripts releasing' is of mine and dates back to JHU workshop in
>>>>>> 2006. Back then, we were hacking the scripts and running experiments
>>>>>> at the same time, so we needed some track of what version of scripts
>>>>>> was used for that particular failing experiment.
>>>>>>
>>>>>> As soon as anyone has some spare time I'd suggest:
>>>>>>
>>>>>> - delete the 'releasing' code in the Makefile
>>>>>> - make sure the main make compiles everything: all moseses, all
>>>>>> auxiliary binaries in scripts etc.
>>>>>> - I'd avoid implementing 'make install', because all the tools in
>>>>>> scripts know where their frieds are sitting in terms of relative
>>>>>> paths. The install would need to preserve the complicated structure
>>>>>> anyway so there's not much point in having the install as 'cp -r'
>>>>>> does the same job.
>>>>>>
>>>>>> Cheers, O.
>>>>>>
>>>>>> On 09/23/2011 09:20 AM, Hieu Hoang wrote:
>>>>>>> agreed, we were having an offlist moan about the same thing. The
>>>>>>> separation between decoding& training, and release date-stamp
>>>>>>> thingy is
>>>>>>> historical and quite silly.
>>>>>>>
>>>>>>> The directories& release procedure has to be rationalised.
>>>>>>>
>>>>>>> Someone will do it eventually...
>>>>>>>
>>>>>>> On 23 September 2011 14:04, Joerg
>>>>> Tiedemann<[email protected]>wrote:
>>>>>>>> By the way, what is the use of a date-stamped directory anyway?
>>>>>>>> I find if rather disturbing that all the binaries and scripts are
>>>>>>>> distributed all over the place.
>>>>>>>> moses-cmd/src
>>>>>>>> moses-chart-cmd/src
>>>>>>>> misc
>>>>>>>> scripts
>>>>>>>> released scripts in a date-stamped directory of your choice
>>>>>>>> ...
>>>>>>>>
>>>>>>>> J�rg
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 22, 2011 at 4:34 PM, Barry Haddow
>>>>>>>>
>>>>>>>> <[email protected]> wrote:
>>>>>>>>> Hi Hieu et al
>>>>>>>>>
>>>>>>>>> I replied to the OP on this, but forgot to CC it to the list.
>>>>>>>>>
>>>>>>>>> There was a change in mert some time in the summer (from Prague)
>>>>>>>>> meaning
>>>>>>>> that
>>>>>>>>
>>>>>>>>> if you run an old mert-moses.perl with a new mert binary, you get
>>>>>>>>> an
>>>>>>>> error
>>>>>>>>
>>>>>>>>> with exit code 3. I suspect this is the problem here since the
>>>>>>>> scripts-rootdir
>>>>>>>>
>>>>>>>>> suggests the scripts are from March. Checking mert.log would
>>>>>>>>> confirm the diagnosis.
>>>>>>>>>
>>>>>>>>> The solution is to rerun 'make release' in the scripts directory,
>>>>>>>>> and
>>>>>>>>> use
>>>>>>>> the
>>>>>>>>
>>>>>>>>> new scripts-rootdir.
>>>>>>>>>
>>>>>>>>> As an aside, I should say that I'm not keen on our two-level make
>>>>>>>>> setup,
>>>>>>>> and
>>>>>>>>
>>>>>>>>> would like to find something simpler. Probably a one level make,
>>>>>>>>> with a
>>>>>>>>> conventional 'make install', but with the default being to
>>>>>>>>> install in a
>>>>>>>> date
>>>>>>>>
>>>>>>>>> stamped directory.
>>>>>>>>>
>>>>>>>>> cheers - Barry
>>>>>>>>>
>>>>>>>>> On Thursday 22 Sep 2011 14:59:26 Hieu Hoang wrote:
>>>>>>>>>> i'm afraid i don't know what the problem is. The n-best-list and
>>>>>>>>>> ini
>>>>>>>>>> files look ok. I'm running mert and moses-chart that was checked
>>>>>>>>>> out
>>>>>>>>>> on the 13th September and ran ok.
>>>>>>>>>>
>>>>>>>>>> i'm not familiar with the mert code so i can't tell you if the
>>>>>>>>>> changes
>>>>>>>>>> you made are good. However, you're welcome to post the changes
>>>>>>>>>> to the
>>>>>>>>>> mailing list and someone might be know better than i do.
>>>>>>>>>>
>>>>>>>>>> On 22/09/2011 15:34, Prasanth K wrote:
>>>>>>>>>>> Hi Hieu,
>>>>>>>>>>>
>>>>>>>>>>> I am attaching the following files:
>>>>>>>>>>>
>>>>>>>>>>> multi-threads_tune-run1.100best.out - first 1000 lines from the
>>>>>>>>>>> multi-threaded decoder
>>>>>>>>>>> single-threads_tune-run1.100best.out - the same from the
>>>>>>>>>>> single-threaded decoder
>>>>>>>>>>>
>>>>>>>>>>> multi-threads_tune-run1.moses.ini - the ini file used at the
>>>>>>>>>>> beginning of the tuning when using threads
>>>>>>>>>>> single-threads_tune-run1.moses.ini - the ini file used at the
>>>>>>>>>>> beginning of the tuning when threads were not used
>>>>>>>>>>> single-threads_tune-run2.moses.ini - the ini file used at the
>>>>>>>>>>> beginning of the second iteration when threads were not used
>>>>>>>>>>>
>>>>>>>>>>> - Prasanth
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 22, 2011 at 10:19 AM, Hieu
>>>>>>>>>>> Hoang<[email protected]<mailto:[email protected]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> can you send me your ini file, and a few lines of the
>>>>>>>>>>> n-best list. For accuracy, send them as attachements, not cut&
>>>>>>>>>>> paste into
>>>>>>>>>>> the email.
>>>>>>>>>>>
>>>>>>>>>>> I'll try& see what the problem is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 22 September 2011 14:57, Prasanth
>>>>>>>>>>> K<[email protected]
>>>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I am facing the same error that Cyrine Nasri mentioned
>>>>>>>>>>> in this thread.
>>>>>>>>>>>
>>>>>>>>>>> I will try and give more information that what has
>>>>>>>>>>> already
>>>>>>>>>>> been mentioned.
>>>>>>>>>>> 1. I was using a single-threaded version of moses
>>>>>>>>>>> until earlier and was having no problem with the experiments
>>>>>>>>>>> using
>>>>>>>> EMS.
>>>>>>>>
>>>>>>>>>>> 2. I recently shifted to a multi-threaded version,
>>>>>>>>>>> and tried the same experiment again with EMS.
>>>>>>>>>>> This time, the tuning process crashes after a single
>>>>>>>>>>> iteration with exactly the same error as mentioned below.
>>>>>>>>>>> 3. I have used 10 threads for decoding in the tuning
>>>>>>>>>>> process, and am using a server with 32Gb ram for running the
>>>>>>>>>>> experiments. (Might not be related, but just thought I should
>>>>>>>>>>> mention!)
>>>>>>>>>>>
>>>>>>>>>>> I am not sure if Cyrine's problem was with the
>>>>>>>>>>> multi-threaded version as well, but could some one point out as
>>>>>>>>>>> to what might be wrong in this picture ?
>>>>>>>>>>>
>>>>>>>>>>> - Prasanth
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 27, 2011 at 5:59 PM, Cyrine NASRI
>>>>>>>>>>>
>>>>>>>>>>> <[email protected]<mailto:[email protected]>>
>>>>>>>> wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>> I 'm trying to launch the mert using this command:
>>>>>>>>>>>
>>>>>>>>>>> ./mert-moses-new.pl<http://mert-moses-new.pl>
>>>>>>>>>>> /users/parole/cnasri/moses_work/corpus/source2TOK
>>>>>>>>>>> /users/parole/cnasri/moses_work/corpus/ref2TOK
>>>>>>>>>>>
>>>>>>>>>>> /users/parole/cnasri/moses_work/moses/moses-cmd/src/moses
>>>>>>>> /users/parole/cnasri/moses_work/moses-scripts/scripts-20110727-154
>>>>>>>> 3/trai n
>>>>>>>>
>>>>>>>>>>> ing/moses.ini --working-dir
>>>>>>>>>>> /users/parole/cnasri/moses_work/tuning/
>>>>>>>>>>> --mertdir /users/parole/cnasri/moses_work/moses/mert
>>>>>>>>>>>
>>>>>>>>>>> But there is only one iteration, after it stops
>>>>>>>>>>> and
>>>>>>>> itshow:
>>>>>>>>>>> Peeking at the beginning of nbestlist to get order
>>>>>>>>>>> of scores: run1.best100.out
>>>>>>>>>>> The decoder returns the scores in this order: d lm
>>>>>>>>>>> w tm
>>>>>>>>>>> tm
>>>>>>>> tm
>>>>>>>>
>>>>>>>>>>> Executing: gzip -f run1.best100.out
>>>>>>>>>>> Scoring the nbestlist.
>>>>>>>>>>> Executing:
>>>>>>>>>>>
>>>>>>>>>>> /users/parole/cnasri/moses_work/moses/mert/extractor
>>>>>>>>>>> --scconfig case:true --scfile run1.scores.dat --ffile
>>>>>>>>>>> run1.features.dat -r
>>>>>>>>>>> /users/parole/cnasri/moses_work/corpus/ref2TOK -n
>>>>>>>>>>> run1.best100.out.gz> extract.out 2> extract.err
>>>>>>>>>>> Executing: \cp -f init.opt run1.init.opt
>>>>>>>>>>> Executing:
>>>>>>>>>>> /users/parole/cnasri/moses_work/moses/mert/mert -d 6
>>>>>>>>>>> --scconfig case:true -n 20 --ffile run1.features.dat --scfile
>>>>>>>>>>> run1.scores.dat --ifile run1.init.opt 2> mert.log Exit code: 3
>>>>>>>>>>> Failed to run mert at ./mert-moses-new.pl
>>>>>>>>>>> <http://mert-moses-new.pl> line 752.
>>>>>>>>>>> and in the mert log :
>>>>>>>>>>>
>>>>>>>>>>> Seeding random numbers with system clock
>>>>>>>>>>>
>>>>>>>>>>> :Too few minimum weights.
>>>>>>>>>>>
>>>>>>>>>>> error could not initialize start point with
>>>>>>>>>>>
>>>>>>>>>>> I have not idea how i resolve this problem.
>>>>>>>>>>> Any idea please?
>>>>>>>>>>>
>>>>>>>>>>> Thank you
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moses-support mailing list
>>>>>>>>>>>
>>>>>>>>>>> [email protected]<mailto:[email protected]>
>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --- J.B.S. Haldane
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moses-support mailing list
>>>>>>>>>>> [email protected]<mailto:[email protected]>
>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --- J.B.S. Haldane
>>>>>>>>> _______________________________________________
>>>>>>>>> Moses-support mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> ******************************************************************
>>>>>>>> ****** ********** J�rg Tiedemann
>>>>>>>> [email protected]
>>>>>>>> Dep. of Linguistics and Philology
>>>>>>>> http://stp.lingfil.uu.se/~joerg/
>>>>>>>> Uppsala University tel: +46
>>>>>>>> (0)18 -
>>>>>>>> 471 1412
>>>>>>>> Box 635, SE-751 26 Uppsala/SWEDEN fax: +46 (0)18 - 471 1094
>>>>>>> _______________________________________________
>>>>>>> Moses-support mailing list
>>>>>>> [email protected]
>>>>>>> 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
>>>>> [email protected]
>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>> _______________________________________________
>>>> Moses-support mailing list
>>>> [email protected]
>>>> 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"
>>>
>>> _______________________________________________
>>> 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
>>
>
> --
> Barry Haddow
> University of Edinburgh
> +44 (0) 131 651 3173
>
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
