Srilm using relative path about kaldi HOT 8 CLOSED

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count is not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected] wrote:

In many egs scripts, srilm binary examiner is using relative path, such as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't intend to
change src code. Such scripts cause errors. So should it be an absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

from kaldi.

I think his point is, if not on the path, should we be using KALDI_ROOT or
../../..?
I don't think we have a convention or a requirement that KALDI_ROOT should
be exported to shell scripts and available there.
We could consider introducing such a convention.
Meanwhile, it might be possible to modify the script to first use
KALDI_ROOT if defined, and otherwise use ../../... E.g.

[ -z $KALDI_ROOT ] && KALDI_ROOT=../../..
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

or whatever. I would consider such a pull request. Of course if Yenda
sees a problem with it I'd take that into account.
Dan

On Mon, Aug 31, 2015 at 9:40 PM, jtrmal [email protected] wrote:

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count is not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected]
wrote:

In many egs scripts, srilm binary examiner is using relative path, such
as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't intend to
change src code. Such scripts cause errors. So should it be an absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

—
Reply to this email directly or view it on GitHub
#110 (comment).

from kaldi.

I understand that.
But even if 'ngram-count' is not on the path, why does it assume that it
is installed in the users own Kaldi environment?

X.

On 09/01/2015 09:40 AM, jtrmal wrote:

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count is not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected]
wrote:

In many egs scripts, srilm binary examiner is using relative path,
such as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't
intend to
change src code. Such scripts cause errors. So should it be an absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

—
Reply to this email directly or view it on GitHub
#110 (comment).

from kaldi.

It doesn't assume it, it simply tries it as the first guess, since there is
no-where else to look.
Dan

On Mon, Aug 31, 2015 at 9:46 PM, Xingyu Na [email protected] wrote:

I understand that.
But even if 'ngram-count' is not on the path, why does it assume that it
is installed in the users own Kaldi environment?

X.

On 09/01/2015 09:40 AM, jtrmal wrote:

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count is not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected]
wrote:

In many egs scripts, srilm binary examiner is using relative path,
such as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't
intend to
change src code. Such scripts cause errors. So should it be an absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

—
Reply to this email directly or view it on GitHub
#110 (comment).

—
Reply to this email directly or view it on GitHub
#110 (comment).

from kaldi.

I see... Your suggestion sounds plausible.

X.

On 09/01/2015 09:49 AM, Daniel Povey wrote:

It doesn't assume it, it simply tries it as the first guess, since
there is
no-where else to look.
Dan

On Mon, Aug 31, 2015 at 9:46 PM, Xingyu Na [email protected]
wrote:

I understand that.
But even if 'ngram-count' is not on the path, why does it assume that it
is installed in the users own Kaldi environment?

X.

On 09/01/2015 09:40 AM, jtrmal wrote:

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count
is not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected]
wrote:

In many egs scripts, srilm binary examiner is using relative path,
such as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't
intend to
change src code. Such scripts cause errors. So should it be an
absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

—
Reply to this email directly or view it on GitHub

#110 (comment).

—
Reply to this email directly or view it on GitHub
#110 (comment).

—
Reply to this email directly or view it on GitHub
#110 (comment).

from kaldi.

Frankly, I'd support the opposite modification -- have it on the path or
the will die (with possibly some helpful message) :)
We have now the "autoconfiguration" mechanism in the tools so I think there
is no reason for scripts to assume much else than just test for the
existence -- most of these scripts were written before the had the
autoconfig via $KALDI_ROOT/tools/env.sh but I'm not sure if it matters now.
y.

On Mon, Aug 31, 2015 at 9:46 PM, Daniel Povey [email protected]
wrote:

I think his point is, if not on the path, should we be using KALDI_ROOT or
../../..?
I don't think we have a convention or a requirement that KALDI_ROOT should
be exported to shell scripts and available there.
We could consider introducing such a convention.
Meanwhile, it might be possible to modify the script to first use
KALDI_ROOT if defined, and otherwise use ../../... E.g.

[ -z $KALDI_ROOT ] && KALDI_ROOT=../../..
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

or whatever. I would consider such a pull request. Of course if Yenda
sees a problem with it I'd take that into account.
Dan

On Mon, Aug 31, 2015 at 9:40 PM, jtrmal [email protected] wrote:

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count is not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected]
wrote:

In many egs scripts, srilm binary examiner is using relative path, such
as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't intend
to
change src code. Such scripts cause errors. So should it be an absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

—
Reply to this email directly or view it on GitHub
#110 (comment).

—
Reply to this email directly or view it on GitHub
#110 (comment).

from kaldi.

I would be OK with just dying.
Dan

On Mon, Aug 31, 2015 at 9:52 PM, jtrmal [email protected] wrote:

Frankly, I'd support the opposite modification -- have it on the path or
the will die (with possibly some helpful message) :)
We have now the "autoconfiguration" mechanism in the tools so I think there
is no reason for scripts to assume much else than just test for the
existence -- most of these scripts were written before the had the
autoconfig via $KALDI_ROOT/tools/env.sh but I'm not sure if it matters now.
y.

On Mon, Aug 31, 2015 at 9:46 PM, Daniel Povey [email protected]
wrote:

I think his point is, if not on the path, should we be using KALDI_ROOT
or
../../..?
I don't think we have a convention or a requirement that KALDI_ROOT
should
be exported to shell scripts and available there.
We could consider introducing such a convention.
Meanwhile, it might be possible to modify the script to first use
KALDI_ROOT if defined, and otherwise use ../../... E.g.

[ -z $KALDI_ROOT ] && KALDI_ROOT=../../..
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

or whatever. I would consider such a pull request. Of course if Yenda
sees a problem with it I'd take that into account.
Dan

On Mon, Aug 31, 2015 at 9:40 PM, jtrmal [email protected]
wrote:

You don't read the code correctly.
The line you are mentioning is just a fallback in case ngram-count is
not
on the path.
Having srilm available on path is the safest solution.
y.

On Mon, Aug 31, 2015 at 9:36 PM, Xingyu Na [email protected]
wrote:

In many egs scripts, srilm binary examiner is using relative path,
such
as:
egs/babel/s5c/local/train_lms_srilm.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh: sdir=pwd
/../../../tools/srilm/bin/i686-m64

In our environment, users of Kaldi are encouraged to use a share
KALDI_ROOT, instead of building their own version if they don't
intend
to
change src code. Such scripts cause errors. So should it be an
absolute
path? aka:
egs/babel/s5c/local/train_lms_srilm.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64
egs/swbd/s5c/local/swbd1_train_lms.sh:
sdir=$KALDI_ROOT/tools/srilm/bin/i686-m64

It should work in most settings.

—
Reply to this email directly or view it on GitHub
#110.

—
Reply to this email directly or view it on GitHub
<#110 (comment)
.

—
Reply to this email directly or view it on GitHub
#110 (comment).

—
Reply to this email directly or view it on GitHub
#110 (comment).

from kaldi.

This issue seems not of anyone's concern but me... Closing it now.

from kaldi.