Menu
▾
▴
kaldi-users — Kaldi Users
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
|
Feb
|
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(7) |
May
(31) |
Jun
(40) |
Jul
(65) |
Aug
(37) |
Sep
(12) |
Oct
(57) |
Nov
(15) |
Dec
(35) |
| 2014 |
Jan
(3) |
Feb
(30) |
Mar
(57) |
Apr
(26) |
May
(49) |
Jun
(26) |
Jul
(63) |
Aug
(33) |
Sep
(20) |
Oct
(153) |
Nov
(62) |
Dec
(20) |
| 2015 |
Jan
(6) |
Feb
(21) |
Mar
(42) |
Apr
(33) |
May
(76) |
Jun
(102) |
Jul
(39) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Daniel P. <dp...@gm...> - 2015-05-18 01:46:13
|
> Thanks for the prompt reply. > > What I want to do is use pairs of (phone,HMM-state) as the targets to train > a DNN. However, after getting these targets I noticed that some of them > occur rarely in the dataset, e.g 40 times in ~30M vectors of data. > Consequently, I would like to prune the decision tree (or stop splitting > during building it) so that eventually all my targets appear at least, say, > 1000 times each. > I tried to use a threshold for the likelihood to control splitting, but I > still did not get the results I expected. > > Is there another way to deal with this matter? It's a little unclear from your question what you problem is. If your targets are really (phone, HMM-state) [e.g. phone = 1 ... 40, hmm-state = 1 ... 3], then the decision tree is not involved at all. If your targets are really pairs (phone, pdf-id) in Kaldi terminology, then yes, some of your targets might be quite infrequent (especially if, in your system, there are word-position-dependent phones). If the issue is caused by word-position-dependent phones, then thresholds like you suggested won't help- in that case it would be better simply to use pdf-id as the target. Otherwise (if there are no word-position-dependent phones), then applying a state-count threshold could help with your immediate problem of low counts, but I'm quite doubtful that it would make any difference to WER in the end. One thing that can be helpful in dealing with these very low-count states is, when dividing by the prior probabilities of states, to divide by the average state posterior computed over the training data, instead of the prior of that state in your training labels. This stops a particular pathology where particular low-count states can get too likely after dividing by the prior. Dan > >> >> >> The reason why that wasn't implemented as a feature is that due to the >> way the tree-clustering was implemented, it would be slightly tricky >> to implement. It would be possible but would require attention from >> someone familiar with the tree-clustering code. (e.g. Hainan >> Do you have any definite reason to believe that this would improve >> results? >> Dan >> >> >> On Sun, May 17, 2015 at 4:58 AM, Yannis Chalkiadakis >> <ha...@ho...> wrote: >> > Hi all, >> > >> > I would like to prevent a leaf from splitting when its size is less than >> > , >> > say , N, or merge it with its parent during bottom-up clustering if its >> > size >> > is less than N. Is this possible? How could I extract the size of the >> > leaf? >> > >> > Thank you in advance for your time and help, >> > Yannis >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > One dashboard for servers and applications across Physical-Virtual-Cloud >> > Widest out-of-the-box monitoring support with 50+ applications >> > Performance metrics, stats and reports that give you Actionable Insights >> > Deep dive visibility with transaction tracing using APM Insight. >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> > _______________________________________________ >> > Kaldi-users mailing list >> > Kal...@li... >> > https://lists.sourceforge.net/lists/listinfo/kaldi-users >> > |
|
From: Yannis C. <ha...@ho...> - 2015-05-17 22:27:28
|
Hi Dan, Thanks for the prompt reply. What I want to do is use pairs of (phone,HMM-state) as the targets to train a DNN. However, after getting these targets I noticed that some of them occur rarely in the dataset, e.g 40 times in ~30M vectors of data. Consequently, I would like to prune the decision tree (or stop splitting during building it) so that eventually all my targets appear at least, say, 1000 times each.I tried to use a threshold for the likelihood to control splitting, but I still did not get the results I expected. Is there another way to deal with this matter? Thank you for the help,Yannis > > > The reason why that wasn't implemented as a feature is that due to the > way the tree-clustering was implemented, it would be slightly tricky > to implement. It would be possible but would require attention from > someone familiar with the tree-clustering code. (e.g. Hainan > Do you have any definite reason to believe that this would improve results? > Dan > > > On Sun, May 17, 2015 at 4:58 AM, Yannis Chalkiadakis > <ha...@ho...> wrote: > > Hi all, > > > > I would like to prevent a leaf from splitting when its size is less than , > > say , N, or merge it with its parent during bottom-up clustering if its size > > is less than N. Is this possible? How could I extract the size of the leaf? > > > > Thank you in advance for your time and help, > > Yannis > > > > > > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > Kaldi-users mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: Daniel P. <dp...@gm...> - 2015-05-17 17:51:11
|
The reason why that wasn't implemented as a feature is that due to the way the tree-clustering was implemented, it would be slightly tricky to implement. It would be possible but would require attention from someone familiar with the tree-clustering code. (e.g. Hainan Do you have any definite reason to believe that this would improve results? Dan On Sun, May 17, 2015 at 4:58 AM, Yannis Chalkiadakis <ha...@ho...> wrote: > Hi all, > > I would like to prevent a leaf from splitting when its size is less than , > say , N, or merge it with its parent during bottom-up clustering if its size > is less than N. Is this possible? How could I extract the size of the leaf? > > Thank you in advance for your time and help, > Yannis > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Yannis C. <ha...@ho...> - 2015-05-17 08:58:49
|
Hi all, I would like to prevent a leaf from splitting when its size is less than , say , N, or merge it with its parent during bottom-up clustering if its size is less than N. Is this possible? How could I extract the size of the leaf? Thank you in advance for your time and help,Yannis |
|
From: Daniel P. <dp...@gm...> - 2015-05-16 02:23:21
|
Ubuntu is a very common variety of Linux and I'm confident that it's
not a problem with Kaldi.
In fact, "isascii" does not appear on line 27 of text-utils.cc.
I think you may have accidentally modified or corrupted that file. Do
"svn revert -R" in that directory to revert to the checked-out
version. "svn status" will let you know how the code has changed.
Dan
On Fri, May 15, 2015 at 10:17 PM, Patrick John Schone
<pat...@ld...> wrote:
> Hi, All,
>
> Sorry to bother you with trivialities, but I hoped that someone might
> know the answer to this question.
>
> I have been using Kaldi on Cygwin for months -- no problems. But now I am
> now trying to compile it on Ubuntu and I keep getting the following problem:
>
>
>
> text-utils.cc:27:17: error: ‘c’ was not declared in this scope
>
> _DEFUN(isascii,(c),int c)
>
> ^
>
> text-utils.cc:27:20: error: expected primary-expression before ‘int’
>
> _DEFUN(isascii,(c),int c)
>
> ^
>
> text-utils.cc:27:25: error: expression list treated as compound expression
> in initializer [-fpermissive]
>
> _DEFUN(isascii,(c),int c)
>
> ^
>
> text-utils.cc:28:1: error: expected ‘,’ or ‘;’ before ‘{’ token
>
> {
>
> ^
>
> make[1]: *** [text-utils.o] Error 1
>
>
>
> This is happening here:
>
> make[1]: Entering directory
> `/home/boisebound/Experiments/OCRandHR/KALDI/src/util'
>
> g++ -msse -msse2 -Wall -I.. -pthread -DKALDI_DOUBLEPRECISION=0
> -DHAVE_POSIX_MEMALIGN -Wno-sign-compare -Wno-unused-local-typedefs
> -Winit-self -DHAVE_EXECINFO_H=1 -rdynamic -DHAVE_CXXABI_H -DHAVE_ATLAS
> -I/home/.../KALDI/tools/ATLAS/include
> -I/home/.../KALDI/tools/openfst/include -DHAVE_OPENFST_GE_10400 -std=c++0x
> -O2 -c -o text-utils.o text-utils.cc
>
>
>
> I have tried compiling with various optimization levels since that helped in
> Cygwin, but no success. Any thoughts?
>
>
>
> Thank you!
>
> Pat Schone
|
|
From: Joan P. <joa...@gm...> - 2015-05-15 14:02:16
|
Hi, Thanks Daniel. As you pointed, the problem was the <eps> in the lexicon. I removed it and know it works as expected. Cheers, Joan. 2015-05-13 18:54 GMT+02:00 Daniel Povey <dp...@gm...>: > I think it's more likely that it's a problem that you are listing > <eps> as a word in your lexicon. That is not allowed. > I am going to check in at some point a change to make_lexicon_fst.pl > that checks the input for <eps> and dies if it sees it. > Dan > > > On Wed, May 13, 2015 at 12:43 PM, Vassil Panayotov > <vas...@gm...> wrote: >> Hi, >> don't have time to look into this in detail, but I wonder if the problem >> could have something to do with the fact you are using "2" in your phone >> set... >> >> Vassil >> >> On Wed, May 13, 2015 at 1:06 PM, Joan Puigcerver <joa...@gm...> wrote: >>> >>> Hi, >>> >>> I am trying to understand the WFST generated by the compile-train-graphs >>> tool. >>> >>> I have both the phonetic and the word transcription of several >>> utterances, and I wanted to use the former for training. However, >>> something does not make sense: in each phone, the arc connecting the >>> first two states has a cost of -0.693359 (which is log(2.0)), even >>> when I call compile-train-graphs with --self-loop-scale=0 or >>> --transition-scale=0. >>> >>> First, I thought the problem could be in the lexicon file, but it is >>> just the list of phonemes, mapping each phoneme to itself. All costs >>> in the lexicon are 0, so I am not sure why the negative costs in the >>> training WFSTs. >>> >>> However, when I use the same recipe, but using the word transcripts >>> instead, the resulting WFST do not have these negative cost. So, I am >>> not sure what I'm doing wrong. >>> >>> I uploaded a .tar.gz with a small example, so you can see understand >>> better the problem: >>> https://www.prhlt.upv.es/~jpuigcerver/phone_vs_words_train_wfst.tar.gz >>> >>> What am I missing? >>> >>> Thank you, >>> Joan. >>> >>> >>> ------------------------------------------------------------------------------ >>> One dashboard for servers and applications across Physical-Virtual-Cloud >>> Widest out-of-the-box monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> _______________________________________________ >>> Kaldi-users mailing list >>> Kal...@li... >>> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> |
|
From: Daniel P. <dp...@gm...> - 2015-05-13 16:54:56
|
I think it's more likely that it's a problem that you are listing <eps> as a word in your lexicon. That is not allowed. I am going to check in at some point a change to make_lexicon_fst.pl that checks the input for <eps> and dies if it sees it. Dan On Wed, May 13, 2015 at 12:43 PM, Vassil Panayotov <vas...@gm...> wrote: > Hi, > don't have time to look into this in detail, but I wonder if the problem > could have something to do with the fact you are using "2" in your phone > set... > > Vassil > > On Wed, May 13, 2015 at 1:06 PM, Joan Puigcerver <joa...@gm...> wrote: >> >> Hi, >> >> I am trying to understand the WFST generated by the compile-train-graphs >> tool. >> >> I have both the phonetic and the word transcription of several >> utterances, and I wanted to use the former for training. However, >> something does not make sense: in each phone, the arc connecting the >> first two states has a cost of -0.693359 (which is log(2.0)), even >> when I call compile-train-graphs with --self-loop-scale=0 or >> --transition-scale=0. >> >> First, I thought the problem could be in the lexicon file, but it is >> just the list of phonemes, mapping each phoneme to itself. All costs >> in the lexicon are 0, so I am not sure why the negative costs in the >> training WFSTs. >> >> However, when I use the same recipe, but using the word transcripts >> instead, the resulting WFST do not have these negative cost. So, I am >> not sure what I'm doing wrong. >> >> I uploaded a .tar.gz with a small example, so you can see understand >> better the problem: >> https://www.prhlt.upv.es/~jpuigcerver/phone_vs_words_train_wfst.tar.gz >> >> What am I missing? >> >> Thank you, >> Joan. >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Vassil P. <vas...@gm...> - 2015-05-13 16:43:26
|
Hi, don't have time to look into this in detail, but I wonder if the problem could have something to do with the fact you are using "2" in your phone set... Vassil On Wed, May 13, 2015 at 1:06 PM, Joan Puigcerver <joa...@gm...> wrote: > Hi, > > I am trying to understand the WFST generated by the compile-train-graphs > tool. > > I have both the phonetic and the word transcription of several > utterances, and I wanted to use the former for training. However, > something does not make sense: in each phone, the arc connecting the > first two states has a cost of -0.693359 (which is log(2.0)), even > when I call compile-train-graphs with --self-loop-scale=0 or > --transition-scale=0. > > First, I thought the problem could be in the lexicon file, but it is > just the list of phonemes, mapping each phoneme to itself. All costs > in the lexicon are 0, so I am not sure why the negative costs in the > training WFSTs. > > However, when I use the same recipe, but using the word transcripts > instead, the resulting WFST do not have these negative cost. So, I am > not sure what I'm doing wrong. > > I uploaded a .tar.gz with a small example, so you can see understand > better the problem: > https://www.prhlt.upv.es/~jpuigcerver/phone_vs_words_train_wfst.tar.gz > > What am I missing? > > Thank you, > Joan. > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Daniel P. <dp...@gm...> - 2015-05-13 15:32:57
|
They are the same thing, except that the tri4_ali might be slightly fresher since it was run after all the iterations of training. Generally speaking, scripts that require an alignment directory can also take a model-training directory. Dan On Wed, May 13, 2015 at 9:05 AM, Yannis Chalkiadakis <ha...@ho...> wrote: > Hello, > > Could someone please explain the difference between the alignments in the > folders e.g. tri4b and tri4b_ali? Does the former contain the final > alignments after training the model? > > Thank you in advance for your time and help, > Yannis > > ________________________________ > > Hi all, > > I want to train a DNN outside KALDI and I would like to acquire the target > labels (HMM states) though KALDI. So far, I have a list of (phone,HMMstate) > tuples for each frame, extracted from the appropriate alignment file. > > > In Kaldi we use the pdf-ids as targets. The pdf-ids correspond to the > clustered states. > > > Are these alignments produced after state-tying? > > > The alignments contain the state-tying information but also the base-phone > information and information about hmm position (they contain transition-ids; > look it up). If you run ali-to-pdf you can get them in terms of pdf-ids, > which correspond to the clustered states. These are the normal targets for > DNN training. > > Furthermore, could someone explain the difference between final.alimdl and > final.mdl models? Which one should be used with e.g. ali-to-phones? > > > The final.mdl is the main model; the final.alimdl is trained without fMLLR > adaptation and is intended to be used in first-pass decoding for adaptation. > However, for ali-to-phones only the transition-model is needed and it's the > same in both cases, so it doesn't matter. > > Dan > > > > Thank you in advance for your time and help, > Yannis > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Yannis C. <ha...@ho...> - 2015-05-13 13:05:39
|
Hello, Could someone please explain the difference between the alignments in the folders e.g. tri4b and tri4b_ali? Does the former contain the final alignments after training the model? Thank you in advance for your time and help,Yannis Hi all, I want to train a DNN outside KALDI and I would like to acquire the target labels (HMM states) though KALDI. So far, I have a list of (phone,HMMstate) tuples for each frame, extracted from the appropriate alignment file. In Kaldi we use the pdf-ids as targets. The pdf-ids correspond to the clustered states. Are these alignments produced after state-tying? The alignments contain the state-tying information but also the base-phone information and information about hmm position (they contain transition-ids; look it up). If you run ali-to-pdf you can get them in terms of pdf-ids, which correspond to the clustered states. These are the normal targets for DNN training. Furthermore, could someone explain the difference between final.alimdl and final.mdl models? Which one should be used with e.g. ali-to-phones? The final.mdl is the main model; the final.alimdl is trained without fMLLR adaptation and is intended to be used in first-pass decoding for adaptation. However, for ali-to-phones only the transition-model is needed and it's the same in both cases, so it doesn't matter. Dan Thank you in advance for your time and help,Yannis ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Kaldi-users mailing list Kal...@li... https://lists.sourceforge.net/lists/listinfo/kaldi-users |
|
From: Jan T. <jt...@gm...> - 2015-05-13 10:53:25
|
$sdata points to the split dir, yes. Inside the split-dir there is the correct parts of the complete files (i.e. parts of e.g. utt2spk and cmvn.scp) y. On Wed, May 13, 2015 at 3:24 AM, Xingyu Na <asr...@gm...> wrote: > Why? $sdata just contain the splitted dirs, while $data contain the > required files, utt2spk and cmvn.scp... > > X. > > > On 05/12/2015 08:49 PM, Jan Trmal wrote: > > Shouldn't it be $sdata ? > y. > > On Tue, May 12, 2015 at 8:57 AM, Xingyu Na <asr...@gm...> wrote: > >> L60 of steps/nnet/make_priors.sh >> [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts >> --utt2spk=ark:$srcdata/utt2spk scp:$srcdata/cmvn.scp ark:- ark:- |" >> should be >> [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts >> --utt2spk=ark:$data/utt2spk scp:$data/cmvn.scp ark:- ark:- |" >> because the "source data dir" is actually $data in this setup. >> >> X. >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> > > > |
|
From: Joan P. <joa...@gm...> - 2015-05-13 10:07:26
|
Hi, I am trying to understand the WFST generated by the compile-train-graphs tool. I have both the phonetic and the word transcription of several utterances, and I wanted to use the former for training. However, something does not make sense: in each phone, the arc connecting the first two states has a cost of -0.693359 (which is log(2.0)), even when I call compile-train-graphs with --self-loop-scale=0 or --transition-scale=0. First, I thought the problem could be in the lexicon file, but it is just the list of phonemes, mapping each phoneme to itself. All costs in the lexicon are 0, so I am not sure why the negative costs in the training WFSTs. However, when I use the same recipe, but using the word transcripts instead, the resulting WFST do not have these negative cost. So, I am not sure what I'm doing wrong. I uploaded a .tar.gz with a small example, so you can see understand better the problem: https://www.prhlt.upv.es/~jpuigcerver/phone_vs_words_train_wfst.tar.gz What am I missing? Thank you, Joan. |
|
From: Xingyu Na <asr...@gm...> - 2015-05-13 01:24:36
|
Why? $sdata just contain the splitted dirs, while $data contain the required files, utt2spk and cmvn.scp... X. On 05/12/2015 08:49 PM, Jan Trmal wrote: > Shouldn't it be $sdata ? > y. > > On Tue, May 12, 2015 at 8:57 AM, Xingyu Na <asr...@gm... > <mailto:asr...@gm...>> wrote: > > L60 of steps/nnet/make_priors.sh > [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts > --utt2spk=ark:$srcdata/utt2spk scp:$srcdata/cmvn.scp ark:- ark:- |" > should be > [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts > --utt2spk=ark:$data/utt2spk scp:$data/cmvn.scp ark:- ark:- |" > because the "source data dir" is actually $data in this setup. > > X. > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across > Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > <mailto:Kal...@li...> > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: Daniel P. <dp...@gm...> - 2015-05-12 18:11:51
|
Yes, it should be $sdata. Committed a fix. Thanks! Dan On Tue, May 12, 2015 at 5:49 AM, Jan Trmal <jt...@gm...> wrote: > Shouldn't it be $sdata ? > y. > > On Tue, May 12, 2015 at 8:57 AM, Xingyu Na <asr...@gm...> wrote: >> >> L60 of steps/nnet/make_priors.sh >> [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts >> --utt2spk=ark:$srcdata/utt2spk scp:$srcdata/cmvn.scp ark:- ark:- |" >> should be >> [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts >> --utt2spk=ark:$data/utt2spk scp:$data/cmvn.scp ark:- ark:- |" >> because the "source data dir" is actually $data in this setup. >> >> X. >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Jan T. <jt...@gm...> - 2015-05-12 12:49:37
|
Shouldn't it be $sdata ? y. On Tue, May 12, 2015 at 8:57 AM, Xingyu Na <asr...@gm...> wrote: > L60 of steps/nnet/make_priors.sh > [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts > --utt2spk=ark:$srcdata/utt2spk scp:$srcdata/cmvn.scp ark:- ark:- |" > should be > [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts > --utt2spk=ark:$data/utt2spk scp:$data/cmvn.scp ark:- ark:- |" > because the "source data dir" is actually $data in this setup. > > X. > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Jan T. <jt...@gm...> - 2015-05-12 10:26:27
|
[Removing the kaldi-users@ and kaldi-developers@] via BCC Kirill, I will review the github howto you've created and we can talk about details afterwards... In the meantime, please try to merge the HEAD of kaldi repository (feel free to use the github mirror), so that we can review the changes. Thanks for all your work! y. On Tue, May 12, 2015 at 6:49 AM, Kirill Katsnelson < kir...@sm...> wrote: > Thanks, an interesting find. I missed it, I believe. You are most probably > correct and that section should apply to the type resolution too. Full > support for C++11 is still not out there; to Microsoft's defense, the value > of the __cplusplus macro does not indicate a C++11 compliance. Which is to > make our lives even harder indeed... Intel's compiler sided with gcc on > this point, IIRC. And Microsoft is notorious for breaking standards in > many, well, interesting ways, no doubt about that. > > FWIW, I got a word from Intel's support today that the bug in the MSBuild > integration I reported together with a proposed fix was released. I have > not tested it yet though. > > -kkm > > > -----Original Message----- > > From: Daniel Povey [mailto:dp...@gm...] > > Sent: 2015-05-11 1914 > > To: Kirill Katsnelson > > Cc: Jan Trmal; kal...@li...; kaldi- > > dev...@li...; 洪孝宗 > > Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 > > > > BTW, this is one of many bugs that I specifically pointed out to the > > Visual Studio people while at Microsoft (and I looked it up just now > > because I remembered checking the standard before, so I knew it was > > there). Their attitude was that compliance with the standard doesn't > > really matter; what really matters is to not break the Windows build. > > Eventually I think I gained a bad reputation in that circle as not > > being sufficiently "with the program". Anyway, I'm willing to patch > > Kaldi to support their broken compiler as far as is reasonable, but it > > doesn't make me very happy. > > > > Dan > > > > > > On Mon, May 11, 2015 at 7:06 PM, Daniel Povey <dp...@gm...> wrote: > > > It isn't a gray area in the standard; see > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf > > > the last paragraph on page 367: > > > If a name does not depend on a template-parameter (as defined in > > > 14.6.2), a declaration (or set of declarations) for that name shall > > be > > > in scope at the point where the name appears in the template > > > definition; the name is bound to the declaration (or declarations) > > > found at that point and this binding is not affected by declarations > > > that are visible at the point of instantiation. > > > > > > Dan > > > > > > > > > On Mon, May 11, 2015 at 2:50 PM, Kirill Katsnelson > > > <kir...@sm...> wrote: > > >> I thought it was but this really appears to be a grey area in the > > standard. But indeed, from the practical standpoint, I think the best > > thing to do is just make all compilers happy. I can figure out if this > > is really undefined C++ later, if there is a theoretical interest. > > >> > > >> -kkm > > >> > > >>> -----Original Message----- > > >>> From: Daniel Povey [mailto:dp...@gm...] > > >>> Sent: 2015-05-11 1444 > > >>> To: Jan Trmal > > >>> Cc: Kirill Katsnelson; kal...@li...; kaldi- > > >>> dev...@li...; 洪孝宗 > > >>> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 > > >>> > > >>> OK fine. > > >>> I'm pretty sure this is a bug in MSVC, that the namespace lookup > > for > > >>> a templated function happens in the context in which the template > > is > > >>> evaluated (as opposed to where it was defined). But it makes sense > > >>> to patch it anyway. > > >>> Dan > > >>> > > >>> > > >>> On Mon, May 11, 2015 at 2:09 PM, Jan Trmal <jt...@gm...> > > wrote: > > >>> > Ok, I will have a.look tmrw. I think I've resolved the types > > issue > > >>> > (last one you mentioned). I generated the patch for openfst, that > > >>> > defines the int types within the openfst namespace - originally > > >>> > they exist on.the highest scope (i.e. ::int32) The patch has > > >>> > something > > >>> like > > >>> > namespace fst { > > >>> > typedef int32 ::int32; > > >>> > } > > >>> > > > >>> > Doping this, the lookup works fine even under the ms c++. > > >>> > To me, this is optimal solution as we have to patch the openfst > > >>> anyway > > >>> > (and my change wont break any code). > > >>> > You can.have a look ať the openfstwin-1.3.3.patch in > > tools/extras. > > >>> > I am open to any suggestion or general discussion on how this > > >>> > should be made better. > > >>> > Y. > > >>> > > > >>> > On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote: > > >>> >> > > >>> >> > Well, the build was not "painless" at all. In fact, the perl > > >>> script > > >>> >> > generated a solution with 600+ projects that simply failed to > > >>> >> > build. VS was churning out dependencies on these, and crashed > > >>> >> > in about 10 minutes of just sitting there with a 100% CPU use. > > >>> >> > Not a single file was compiled, so I think it was just > > >>> >> > autogenerating > > >>> dependencies at this point. > > >>> >> > > >>> >> Build systems on Windows are pretty broken. I think in > > Microsoft > > >>> >> they use some other system, not the one used in VS, which is not > > >>> >> publicly released. > > >>> >> > > >>> >> > I did not try to build from the command line though. Am I > > >>> >> > understanding it would compile? > > >>> >> > > >>> >> No, not everything would compile. Sometimes the VS compiler > > just > > >>> crashes. > > >>> >> > > >>> >> > What I did not like about the existing system is that I could > > >>> >> > not plug in CUDA or intel compiler. It is extremely rigid in > > >>> >> > the > > >>> option > > >>> >> > part, and to change compiler options you are most likely to > > >>> >> > change the perl code that generates the project files, or > > >>> >> > modify the different MSBuild include files (called "property > > >>> >> > sheets" in this > > >>> >> > context) that are interplaying quite non-trivially. No, I have > > >>> >> > spent a few days on the build system not for a love of > > >>> >> > tinkering with MSBuils at all! :) > > >>> >> > > >>> >> What we committed was just a hack to try to get something > > working. > > >>> >> IIRC we just looked at the build files generated by VS to try to > > >>> >> guess what the format of those files was supposed to be; I'm not > > >>> sure > > >>> >> that they are really intended to be human readable/writable > > >>> >> (unless that human really loves XML). > > >>> >> > > >>> >> > Anyway, you can look at it at > > >>> >> > https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I > > >>> >> > have not updated the branch in a while) If you think this is > > >>> >> > not an acceptable solution, I'm just dropping the ball, no > > >>> >> > offence taken, naturally. I can maintain this as an > > "unofficial > > >>> >> > port" for a > > >>> while. > > >>> >> > In any case, build is the least problem, as Dan has pointed > > out > > >>> already... > > >>> >> > > > >>> >> > The biggest (in the number of changed lines) changes I had to > > >>> >> > make were in the namespace using declarations, because of > > >>> >> > conflicts between the types > > >>> >> > int32 and friends from different namespaces. I ended up > > reading > > >>> the > > >>> >> > C++ standard to understand whether gcc, icl or msvc is > > "correct" > > >>> in > > >>> >> > different cases they are complaining about, and the standard > > >>> >> > appears not to define any behavior there. These changes I > > would > > >>> >> > prefer accepted into the mainline of development, because they > > >>> >> > are > > >>> harder to maintain in a fork. > > >>> >> > > >>> >> In any case where you have to do something like typedef > > >>> >> kaldi::int32 int32, we should definitely get this committed- > > talk to Yenda. > > >>> >> Actually, this is really a bug in OpenFST which they haven't > > >>> >> fixed yet. There is a "proper" POSIX way to get types like > > >>> >> int32, which > > >>> we > > >>> >> use in Kaldi, but in OpenFst they do it in a different, ad-hoc > > >>> >> way which sometimes generates different types (e.g. on a system > > >>> >> where > > >>> int > > >>> >> and long int are both 32-bit). So the Kaldi int32 and the > > >>> >> OpenFst > > >>> >> int32 end up being different, incompatible types. > > >>> >> > > >>> >> Dan > > >>> >> > > >>> >> > > >>> >> >> -----Original Message----- > > >>> >> >> From: Jan Trmal [mailto:jt...@gm...] > > >>> >> >> Sent: 2015-05-11 0201 > > >>> >> >> To: Dan Povey > > >>> >> >> Cc: Kirill Katsnelson; kaldi- > > dev...@li...; > > >>> >> >> kaldi- us...@li...; 洪孝宗 > > >>> >> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 > > >>> >> >> > > >>> >> >> Guys, the migration to git is "unofficially" done -- unless > > we > > >>> >> >> find some problems with it, the repo > > >>> >> >> (https://github.com/kaldi- > > >>> >> >> asr/kaldi.git) will stay as it is now. > > >>> >> >> > > >>> >> >> Kirill, there is no reason why wait. We should start working > > >>> >> >> on > > >>> it. > > >>> >> >> I propose you could first send the Kaldi code patches -- I > > >>> >> >> actually worked on this and I'm able to compile Kaldi, so > > this > > >>> >> >> should be quite straightforward, provided you will generate > > >>> >> >> the > > >>> diff against the HEAD. > > >>> >> >> > > >>> >> >> Then we can start looking at the "build system". I > > understand > > >>> >> >> your reasons and I think they might be legit. My feeling is, > > >>> >> >> however, that a lot of people are not using MSBuild and will > > >>> >> >> expect the MSVC solution, just because this is how they > > >>> >> >> usually work. I haven't tested it, but you should be able to > > >>> >> >> use the current SLN to build the binaries from command line - > > - > > >>> >> >> that > > >>> should > > >>> >> >> be completely painless -- but again, I haven't tested it. > > >>> >> >> y. > > >>> >> >> > > >>> >> >> > > >>> >> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey > > >>> >> >> <dp...@gm...> > > >>> wrote: > > >>> >> >> > > >>> >> >> > > >>> >> >> >> To the extent that your patches are simple fixes and > > >>> >> >> minor changes to > > >>> >> >> >> the code, I think we could apply them. Perhaps you > > >>> could > > >>> >> >> work with > > >>> >> >> >> Yenda to get your changes checked? > > >>> >> >> > > > >>> >> >> > Easy enough, and as easy to hold till the migration > > is > > >>> done. > > >>> >> >> Was there a change in the plans? > > >>> >> >> > > >>> >> >> Not really a change in the plans, but we don't have a > > >>> definite > > >>> >> >> timeline for migrating to git, and it could be that > > >>> >> >> we'll keep the svn > > >>> >> >> as upstream for a while. Your changes seem reasonable, > > >>> >> >> but I think it > > >>> >> >> would be better to get things started now rather than > > >>> later. > > >>> >> >> The > > >>> >> >> git/svn issues should not be that hard. Just start > > >>> >> >> sending patches to > > >>> >> >> Yenda and we'll handle your changes bit by bit. > > >>> >> >> Dan > > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > > > >>> >> >> >> If you update your git repo to > > >>> >> >> >> point to the current code, then a patch should be > > >>> >> >> applicable by the > > >>> >> >> >> program "patch" to the svn repo too. > > >>> >> >> > > > >>> >> >> > There are many changes, and I certainly want to split > > >>> >> >> the patch so it is readable. One megapatch is not reviewable. > > >>> >> >> > > > >>> >> >> >> Regarding your build approach, you could send me and > > >>> >> >> Yenda some details > > >>> >> >> >> about how you did it, and we could consider whether > > >>> >> >> to support that. > > >>> >> >> > > > >>> >> >> > There's a Powershell script that takes information > > >>> >> >> from every src/*/Makefile into a simple declarative MSBuild > > >>> >> >> script $dirname.kwproj, and a top-level MSBuild "makefile" > > >>> >> >> that drives the whole thing. A little bit more complex than > > >>> >> >> that to allow for > > >>> >> >> user- defined options, but generally this is it. This > > supports > > >>> >> >> building libraries, tools, tests and running the tests with > > >>> >> >> command line switches. The whole thing pretty much mimics a > > >>> >> >> linux make process but using MS tools. > > >>> >> >> > > > >>> >> >> >> I don't think it makes sense to try to maintain a > > >>> >> >> parallel > > >>> >> >> "windows- > > >>> >> >> >> compatible" version of the scripts, if there are > > >>> >> >> larger changes > > >>> >> >> >> required there. > > >>> >> >> > > > >>> >> >> > I was targeting for no changes at all. There maybe a > > >>> >> >> few very small patches that supposed not to break > > compatibility. > > >>> >> >> > > > >>> >> >> >> Anyway you depend on cygwin for scripting, and the > > set > > >>> >> >> >> of people who want to run cygwin and build with MSVC > > >>> >> >> is probably > > >>> >> >> >> limited enough that I don't think it makes sense for > > >>> >> >> us to try to > > >>> >> >> >> support it. > > >>> >> >> > > > >>> >> >> > This is not as simple a choice as it seems at first. > > >>> >> >> Alex Hung just posted a trick to build CUDA under Cygwin; > > >>> >> >> before he > > >>> did > > >>> >> >> I thought it was not possible. MKL is another story. I would > > >>> >> >> rather build under native Windows than try to pull this > > >>> >> >> monster into the Cygwin build environment. > > >>> >> >> > > > >>> >> >> > -kkm > > >>> >> >> > > > >>> >> >> > > >>> >> >> > > >>> >> > > |
|
From: Xingyu Na <asr...@gm...> - 2015-05-12 06:58:23
|
L60 of steps/nnet/make_priors.sh [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts --utt2spk=ark:$srcdata/utt2spk scp:$srcdata/cmvn.scp ark:- ark:- |" should be [ ! -z "$cmvn_opts" ] && feats="$feats apply-cmvn $cmvn_opts --utt2spk=ark:$data/utt2spk scp:$data/cmvn.scp ark:- ark:- |" because the "source data dir" is actually $data in this setup. X. |
|
From: Kirill K. <kir...@sm...> - 2015-05-12 04:50:05
|
Thanks, an interesting find. I missed it, I believe. You are most probably correct and that section should apply to the type resolution too. Full support for C++11 is still not out there; to Microsoft's defense, the value of the __cplusplus macro does not indicate a C++11 compliance. Which is to make our lives even harder indeed... Intel's compiler sided with gcc on this point, IIRC. And Microsoft is notorious for breaking standards in many, well, interesting ways, no doubt about that. FWIW, I got a word from Intel's support today that the bug in the MSBuild integration I reported together with a proposed fix was released. I have not tested it yet though. -kkm > -----Original Message----- > From: Daniel Povey [mailto:dp...@gm...] > Sent: 2015-05-11 1914 > To: Kirill Katsnelson > Cc: Jan Trmal; kal...@li...; kaldi- > dev...@li...; 洪孝宗 > Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 > > BTW, this is one of many bugs that I specifically pointed out to the > Visual Studio people while at Microsoft (and I looked it up just now > because I remembered checking the standard before, so I knew it was > there). Their attitude was that compliance with the standard doesn't > really matter; what really matters is to not break the Windows build. > Eventually I think I gained a bad reputation in that circle as not > being sufficiently "with the program". Anyway, I'm willing to patch > Kaldi to support their broken compiler as far as is reasonable, but it > doesn't make me very happy. > > Dan > > > On Mon, May 11, 2015 at 7:06 PM, Daniel Povey <dp...@gm...> wrote: > > It isn't a gray area in the standard; see > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf > > the last paragraph on page 367: > > If a name does not depend on a template-parameter (as defined in > > 14.6.2), a declaration (or set of declarations) for that name shall > be > > in scope at the point where the name appears in the template > > definition; the name is bound to the declaration (or declarations) > > found at that point and this binding is not affected by declarations > > that are visible at the point of instantiation. > > > > Dan > > > > > > On Mon, May 11, 2015 at 2:50 PM, Kirill Katsnelson > > <kir...@sm...> wrote: > >> I thought it was but this really appears to be a grey area in the > standard. But indeed, from the practical standpoint, I think the best > thing to do is just make all compilers happy. I can figure out if this > is really undefined C++ later, if there is a theoretical interest. > >> > >> -kkm > >> > >>> -----Original Message----- > >>> From: Daniel Povey [mailto:dp...@gm...] > >>> Sent: 2015-05-11 1444 > >>> To: Jan Trmal > >>> Cc: Kirill Katsnelson; kal...@li...; kaldi- > >>> dev...@li...; 洪孝宗 > >>> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 > >>> > >>> OK fine. > >>> I'm pretty sure this is a bug in MSVC, that the namespace lookup > for > >>> a templated function happens in the context in which the template > is > >>> evaluated (as opposed to where it was defined). But it makes sense > >>> to patch it anyway. > >>> Dan > >>> > >>> > >>> On Mon, May 11, 2015 at 2:09 PM, Jan Trmal <jt...@gm...> > wrote: > >>> > Ok, I will have a.look tmrw. I think I've resolved the types > issue > >>> > (last one you mentioned). I generated the patch for openfst, that > >>> > defines the int types within the openfst namespace - originally > >>> > they exist on.the highest scope (i.e. ::int32) The patch has > >>> > something > >>> like > >>> > namespace fst { > >>> > typedef int32 ::int32; > >>> > } > >>> > > >>> > Doping this, the lookup works fine even under the ms c++. > >>> > To me, this is optimal solution as we have to patch the openfst > >>> anyway > >>> > (and my change wont break any code). > >>> > You can.have a look ať the openfstwin-1.3.3.patch in > tools/extras. > >>> > I am open to any suggestion or general discussion on how this > >>> > should be made better. > >>> > Y. > >>> > > >>> > On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote: > >>> >> > >>> >> > Well, the build was not "painless" at all. In fact, the perl > >>> script > >>> >> > generated a solution with 600+ projects that simply failed to > >>> >> > build. VS was churning out dependencies on these, and crashed > >>> >> > in about 10 minutes of just sitting there with a 100% CPU use. > >>> >> > Not a single file was compiled, so I think it was just > >>> >> > autogenerating > >>> dependencies at this point. > >>> >> > >>> >> Build systems on Windows are pretty broken. I think in > Microsoft > >>> >> they use some other system, not the one used in VS, which is not > >>> >> publicly released. > >>> >> > >>> >> > I did not try to build from the command line though. Am I > >>> >> > understanding it would compile? > >>> >> > >>> >> No, not everything would compile. Sometimes the VS compiler > just > >>> crashes. > >>> >> > >>> >> > What I did not like about the existing system is that I could > >>> >> > not plug in CUDA or intel compiler. It is extremely rigid in > >>> >> > the > >>> option > >>> >> > part, and to change compiler options you are most likely to > >>> >> > change the perl code that generates the project files, or > >>> >> > modify the different MSBuild include files (called "property > >>> >> > sheets" in this > >>> >> > context) that are interplaying quite non-trivially. No, I have > >>> >> > spent a few days on the build system not for a love of > >>> >> > tinkering with MSBuils at all! :) > >>> >> > >>> >> What we committed was just a hack to try to get something > working. > >>> >> IIRC we just looked at the build files generated by VS to try to > >>> >> guess what the format of those files was supposed to be; I'm not > >>> sure > >>> >> that they are really intended to be human readable/writable > >>> >> (unless that human really loves XML). > >>> >> > >>> >> > Anyway, you can look at it at > >>> >> > https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I > >>> >> > have not updated the branch in a while) If you think this is > >>> >> > not an acceptable solution, I'm just dropping the ball, no > >>> >> > offence taken, naturally. I can maintain this as an > "unofficial > >>> >> > port" for a > >>> while. > >>> >> > In any case, build is the least problem, as Dan has pointed > out > >>> already... > >>> >> > > >>> >> > The biggest (in the number of changed lines) changes I had to > >>> >> > make were in the namespace using declarations, because of > >>> >> > conflicts between the types > >>> >> > int32 and friends from different namespaces. I ended up > reading > >>> the > >>> >> > C++ standard to understand whether gcc, icl or msvc is > "correct" > >>> in > >>> >> > different cases they are complaining about, and the standard > >>> >> > appears not to define any behavior there. These changes I > would > >>> >> > prefer accepted into the mainline of development, because they > >>> >> > are > >>> harder to maintain in a fork. > >>> >> > >>> >> In any case where you have to do something like typedef > >>> >> kaldi::int32 int32, we should definitely get this committed- > talk to Yenda. > >>> >> Actually, this is really a bug in OpenFST which they haven't > >>> >> fixed yet. There is a "proper" POSIX way to get types like > >>> >> int32, which > >>> we > >>> >> use in Kaldi, but in OpenFst they do it in a different, ad-hoc > >>> >> way which sometimes generates different types (e.g. on a system > >>> >> where > >>> int > >>> >> and long int are both 32-bit). So the Kaldi int32 and the > >>> >> OpenFst > >>> >> int32 end up being different, incompatible types. > >>> >> > >>> >> Dan > >>> >> > >>> >> > >>> >> >> -----Original Message----- > >>> >> >> From: Jan Trmal [mailto:jt...@gm...] > >>> >> >> Sent: 2015-05-11 0201 > >>> >> >> To: Dan Povey > >>> >> >> Cc: Kirill Katsnelson; kaldi- > dev...@li...; > >>> >> >> kaldi- us...@li...; 洪孝宗 > >>> >> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 > >>> >> >> > >>> >> >> Guys, the migration to git is "unofficially" done -- unless > we > >>> >> >> find some problems with it, the repo > >>> >> >> (https://github.com/kaldi- > >>> >> >> asr/kaldi.git) will stay as it is now. > >>> >> >> > >>> >> >> Kirill, there is no reason why wait. We should start working > >>> >> >> on > >>> it. > >>> >> >> I propose you could first send the Kaldi code patches -- I > >>> >> >> actually worked on this and I'm able to compile Kaldi, so > this > >>> >> >> should be quite straightforward, provided you will generate > >>> >> >> the > >>> diff against the HEAD. > >>> >> >> > >>> >> >> Then we can start looking at the "build system". I > understand > >>> >> >> your reasons and I think they might be legit. My feeling is, > >>> >> >> however, that a lot of people are not using MSBuild and will > >>> >> >> expect the MSVC solution, just because this is how they > >>> >> >> usually work. I haven't tested it, but you should be able to > >>> >> >> use the current SLN to build the binaries from command line - > - > >>> >> >> that > >>> should > >>> >> >> be completely painless -- but again, I haven't tested it. > >>> >> >> y. > >>> >> >> > >>> >> >> > >>> >> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey > >>> >> >> <dp...@gm...> > >>> wrote: > >>> >> >> > >>> >> >> > >>> >> >> >> To the extent that your patches are simple fixes and > >>> >> >> minor changes to > >>> >> >> >> the code, I think we could apply them. Perhaps you > >>> could > >>> >> >> work with > >>> >> >> >> Yenda to get your changes checked? > >>> >> >> > > >>> >> >> > Easy enough, and as easy to hold till the migration > is > >>> done. > >>> >> >> Was there a change in the plans? > >>> >> >> > >>> >> >> Not really a change in the plans, but we don't have a > >>> definite > >>> >> >> timeline for migrating to git, and it could be that > >>> >> >> we'll keep the svn > >>> >> >> as upstream for a while. Your changes seem reasonable, > >>> >> >> but I think it > >>> >> >> would be better to get things started now rather than > >>> later. > >>> >> >> The > >>> >> >> git/svn issues should not be that hard. Just start > >>> >> >> sending patches to > >>> >> >> Yenda and we'll handle your changes bit by bit. > >>> >> >> Dan > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > > >>> >> >> >> If you update your git repo to > >>> >> >> >> point to the current code, then a patch should be > >>> >> >> applicable by the > >>> >> >> >> program "patch" to the svn repo too. > >>> >> >> > > >>> >> >> > There are many changes, and I certainly want to split > >>> >> >> the patch so it is readable. One megapatch is not reviewable. > >>> >> >> > > >>> >> >> >> Regarding your build approach, you could send me and > >>> >> >> Yenda some details > >>> >> >> >> about how you did it, and we could consider whether > >>> >> >> to support that. > >>> >> >> > > >>> >> >> > There's a Powershell script that takes information > >>> >> >> from every src/*/Makefile into a simple declarative MSBuild > >>> >> >> script $dirname.kwproj, and a top-level MSBuild "makefile" > >>> >> >> that drives the whole thing. A little bit more complex than > >>> >> >> that to allow for > >>> >> >> user- defined options, but generally this is it. This > supports > >>> >> >> building libraries, tools, tests and running the tests with > >>> >> >> command line switches. The whole thing pretty much mimics a > >>> >> >> linux make process but using MS tools. > >>> >> >> > > >>> >> >> >> I don't think it makes sense to try to maintain a > >>> >> >> parallel > >>> >> >> "windows- > >>> >> >> >> compatible" version of the scripts, if there are > >>> >> >> larger changes > >>> >> >> >> required there. > >>> >> >> > > >>> >> >> > I was targeting for no changes at all. There maybe a > >>> >> >> few very small patches that supposed not to break > compatibility. > >>> >> >> > > >>> >> >> >> Anyway you depend on cygwin for scripting, and the > set > >>> >> >> >> of people who want to run cygwin and build with MSVC > >>> >> >> is probably > >>> >> >> >> limited enough that I don't think it makes sense for > >>> >> >> us to try to > >>> >> >> >> support it. > >>> >> >> > > >>> >> >> > This is not as simple a choice as it seems at first. > >>> >> >> Alex Hung just posted a trick to build CUDA under Cygwin; > >>> >> >> before he > >>> did > >>> >> >> I thought it was not possible. MKL is another story. I would > >>> >> >> rather build under native Windows than try to pull this > >>> >> >> monster into the Cygwin build environment. > >>> >> >> > > >>> >> >> > -kkm > >>> >> >> > > >>> >> >> > >>> >> >> > >>> >> > |
|
From: Daniel P. <dp...@gm...> - 2015-05-12 02:13:45
|
BTW, this is one of many bugs that I specifically pointed out to the Visual Studio people while at Microsoft (and I looked it up just now because I remembered checking the standard before, so I knew it was there). Their attitude was that compliance with the standard doesn't really matter; what really matters is to not break the Windows build. Eventually I think I gained a bad reputation in that circle as not being sufficiently "with the program". Anyway, I'm willing to patch Kaldi to support their broken compiler as far as is reasonable, but it doesn't make me very happy. Dan On Mon, May 11, 2015 at 7:06 PM, Daniel Povey <dp...@gm...> wrote: > It isn't a gray area in the standard; see > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf > the last paragraph on page 367: > If a name does not depend on a template-parameter (as defined in > 14.6.2), a declaration (or set of declarations) for that name shall be > in scope at the point where the name appears in the template > definition; the name is bound to the declaration (or declarations) > found at that point and this binding is not affected by declarations > that are visible at the point of instantiation. > > Dan > > > On Mon, May 11, 2015 at 2:50 PM, Kirill Katsnelson > <kir...@sm...> wrote: >> I thought it was but this really appears to be a grey area in the standard. But indeed, from the practical standpoint, I think the best thing to do is just make all compilers happy. I can figure out if this is really undefined C++ later, if there is a theoretical interest. >> >> -kkm >> >>> -----Original Message----- >>> From: Daniel Povey [mailto:dp...@gm...] >>> Sent: 2015-05-11 1444 >>> To: Jan Trmal >>> Cc: Kirill Katsnelson; kal...@li...; kaldi- >>> dev...@li...; 洪孝宗 >>> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 >>> >>> OK fine. >>> I'm pretty sure this is a bug in MSVC, that the namespace lookup for a >>> templated function happens in the context in which the template is >>> evaluated (as opposed to where it was defined). But it makes sense to >>> patch it anyway. >>> Dan >>> >>> >>> On Mon, May 11, 2015 at 2:09 PM, Jan Trmal <jt...@gm...> wrote: >>> > Ok, I will have a.look tmrw. I think I've resolved the types issue >>> > (last one you mentioned). I generated the patch for openfst, that >>> > defines the int types within the openfst namespace - originally they >>> > exist on.the highest scope (i.e. ::int32) The patch has something >>> like >>> > namespace fst { >>> > typedef int32 ::int32; >>> > } >>> > >>> > Doping this, the lookup works fine even under the ms c++. >>> > To me, this is optimal solution as we have to patch the openfst >>> anyway >>> > (and my change wont break any code). >>> > You can.have a look ať the openfstwin-1.3.3.patch in tools/extras. >>> > I am open to any suggestion or general discussion on how this should >>> > be made better. >>> > Y. >>> > >>> > On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote: >>> >> >>> >> > Well, the build was not "painless" at all. In fact, the perl >>> script >>> >> > generated a solution with 600+ projects that simply failed to >>> >> > build. VS was churning out dependencies on these, and crashed in >>> >> > about 10 minutes of just sitting there with a 100% CPU use. Not a >>> >> > single file was compiled, so I think it was just autogenerating >>> dependencies at this point. >>> >> >>> >> Build systems on Windows are pretty broken. I think in Microsoft >>> >> they use some other system, not the one used in VS, which is not >>> >> publicly released. >>> >> >>> >> > I did not try to build from the command line though. Am I >>> >> > understanding it would compile? >>> >> >>> >> No, not everything would compile. Sometimes the VS compiler just >>> crashes. >>> >> >>> >> > What I did not like about the existing system is that I could not >>> >> > plug in CUDA or intel compiler. It is extremely rigid in the >>> option >>> >> > part, and to change compiler options you are most likely to change >>> >> > the perl code that generates the project files, or modify the >>> >> > different MSBuild include files (called "property sheets" in this >>> >> > context) that are interplaying quite non-trivially. No, I have >>> >> > spent a few days on the build system not for a love of tinkering >>> >> > with MSBuils at all! :) >>> >> >>> >> What we committed was just a hack to try to get something working. >>> >> IIRC we just looked at the build files generated by VS to try to >>> >> guess what the format of those files was supposed to be; I'm not >>> sure >>> >> that they are really intended to be human readable/writable (unless >>> >> that human really loves XML). >>> >> >>> >> > Anyway, you can look at it at >>> >> > https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I have >>> >> > not updated the branch in a while) If you think this is not an >>> >> > acceptable solution, I'm just dropping the ball, no offence taken, >>> >> > naturally. I can maintain this as an "unofficial port" for a >>> while. >>> >> > In any case, build is the least problem, as Dan has pointed out >>> already... >>> >> > >>> >> > The biggest (in the number of changed lines) changes I had to make >>> >> > were in the namespace using declarations, because of conflicts >>> >> > between the types >>> >> > int32 and friends from different namespaces. I ended up reading >>> the >>> >> > C++ standard to understand whether gcc, icl or msvc is "correct" >>> in >>> >> > different cases they are complaining about, and the standard >>> >> > appears not to define any behavior there. These changes I would >>> >> > prefer accepted into the mainline of development, because they are >>> harder to maintain in a fork. >>> >> >>> >> In any case where you have to do something like typedef kaldi::int32 >>> >> int32, we should definitely get this committed- talk to Yenda. >>> >> Actually, this is really a bug in OpenFST which they haven't fixed >>> >> yet. There is a "proper" POSIX way to get types like int32, which >>> we >>> >> use in Kaldi, but in OpenFst they do it in a different, ad-hoc way >>> >> which sometimes generates different types (e.g. on a system where >>> int >>> >> and long int are both 32-bit). So the Kaldi int32 and the OpenFst >>> >> int32 end up being different, incompatible types. >>> >> >>> >> Dan >>> >> >>> >> >>> >> >> -----Original Message----- >>> >> >> From: Jan Trmal [mailto:jt...@gm...] >>> >> >> Sent: 2015-05-11 0201 >>> >> >> To: Dan Povey >>> >> >> Cc: Kirill Katsnelson; kal...@li...; >>> >> >> kaldi- us...@li...; 洪孝宗 >>> >> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 >>> >> >> >>> >> >> Guys, the migration to git is "unofficially" done -- unless we >>> >> >> find some problems with it, the repo (https://github.com/kaldi- >>> >> >> asr/kaldi.git) will stay as it is now. >>> >> >> >>> >> >> Kirill, there is no reason why wait. We should start working on >>> it. >>> >> >> I propose you could first send the Kaldi code patches -- I >>> >> >> actually worked on this and I'm able to compile Kaldi, so this >>> >> >> should be quite straightforward, provided you will generate the >>> diff against the HEAD. >>> >> >> >>> >> >> Then we can start looking at the "build system". I understand >>> >> >> your reasons and I think they might be legit. My feeling is, >>> >> >> however, that a lot of people are not using MSBuild and will >>> >> >> expect the MSVC solution, just because this is how they usually >>> >> >> work. I haven't tested it, but you should be able to use the >>> >> >> current SLN to build the binaries from command line -- that >>> should >>> >> >> be completely painless -- but again, I haven't tested it. >>> >> >> y. >>> >> >> >>> >> >> >>> >> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey <dp...@gm...> >>> wrote: >>> >> >> >>> >> >> >>> >> >> >> To the extent that your patches are simple fixes and >>> >> >> minor changes to >>> >> >> >> the code, I think we could apply them. Perhaps you >>> could >>> >> >> work with >>> >> >> >> Yenda to get your changes checked? >>> >> >> > >>> >> >> > Easy enough, and as easy to hold till the migration is >>> done. >>> >> >> Was there a change in the plans? >>> >> >> >>> >> >> Not really a change in the plans, but we don't have a >>> definite >>> >> >> timeline for migrating to git, and it could be that we'll >>> >> >> keep the svn >>> >> >> as upstream for a while. Your changes seem reasonable, but >>> >> >> I think it >>> >> >> would be better to get things started now rather than >>> later. >>> >> >> The >>> >> >> git/svn issues should not be that hard. Just start sending >>> >> >> patches to >>> >> >> Yenda and we'll handle your changes bit by bit. >>> >> >> Dan >>> >> >> >>> >> >> >>> >> >> >>> >> >> > >>> >> >> >> If you update your git repo to >>> >> >> >> point to the current code, then a patch should be >>> >> >> applicable by the >>> >> >> >> program "patch" to the svn repo too. >>> >> >> > >>> >> >> > There are many changes, and I certainly want to split the >>> >> >> patch so it is readable. One megapatch is not reviewable. >>> >> >> > >>> >> >> >> Regarding your build approach, you could send me and >>> >> >> Yenda some details >>> >> >> >> about how you did it, and we could consider whether to >>> >> >> support that. >>> >> >> > >>> >> >> > There's a Powershell script that takes information from >>> >> >> every src/*/Makefile into a simple declarative MSBuild script >>> >> >> $dirname.kwproj, and a top-level MSBuild "makefile" that drives >>> >> >> the whole thing. A little bit more complex than that to allow for >>> >> >> user- defined options, but generally this is it. This supports >>> >> >> building libraries, tools, tests and running the tests with >>> >> >> command line switches. The whole thing pretty much mimics a linux >>> >> >> make process but using MS tools. >>> >> >> > >>> >> >> >> I don't think it makes sense to try to maintain a >>> >> >> parallel >>> >> >> "windows- >>> >> >> >> compatible" version of the scripts, if there are larger >>> >> >> changes >>> >> >> >> required there. >>> >> >> > >>> >> >> > I was targeting for no changes at all. There maybe a few >>> >> >> very small patches that supposed not to break compatibility. >>> >> >> > >>> >> >> >> Anyway you depend on cygwin for scripting, and the set >>> >> >> >> of people who want to run cygwin and build with MSVC is >>> >> >> probably >>> >> >> >> limited enough that I don't think it makes sense for us >>> >> >> to try to >>> >> >> >> support it. >>> >> >> > >>> >> >> > This is not as simple a choice as it seems at first. Alex >>> >> >> Hung just posted a trick to build CUDA under Cygwin; before he >>> did >>> >> >> I thought it was not possible. MKL is another story. I would >>> >> >> rather build under native Windows than try to pull this monster >>> >> >> into the Cygwin build environment. >>> >> >> > >>> >> >> > -kkm >>> >> >> > >>> >> >> >>> >> >> >>> >> > |
|
From: Daniel P. <dp...@gm...> - 2015-05-12 02:06:44
|
It isn't a gray area in the standard; see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf the last paragraph on page 367: If a name does not depend on a template-parameter (as defined in 14.6.2), a declaration (or set of declarations) for that name shall be in scope at the point where the name appears in the template definition; the name is bound to the declaration (or declarations) found at that point and this binding is not affected by declarations that are visible at the point of instantiation. Dan On Mon, May 11, 2015 at 2:50 PM, Kirill Katsnelson <kir...@sm...> wrote: > I thought it was but this really appears to be a grey area in the standard. But indeed, from the practical standpoint, I think the best thing to do is just make all compilers happy. I can figure out if this is really undefined C++ later, if there is a theoretical interest. > > -kkm > >> -----Original Message----- >> From: Daniel Povey [mailto:dp...@gm...] >> Sent: 2015-05-11 1444 >> To: Jan Trmal >> Cc: Kirill Katsnelson; kal...@li...; kaldi- >> dev...@li...; 洪孝宗 >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 >> >> OK fine. >> I'm pretty sure this is a bug in MSVC, that the namespace lookup for a >> templated function happens in the context in which the template is >> evaluated (as opposed to where it was defined). But it makes sense to >> patch it anyway. >> Dan >> >> >> On Mon, May 11, 2015 at 2:09 PM, Jan Trmal <jt...@gm...> wrote: >> > Ok, I will have a.look tmrw. I think I've resolved the types issue >> > (last one you mentioned). I generated the patch for openfst, that >> > defines the int types within the openfst namespace - originally they >> > exist on.the highest scope (i.e. ::int32) The patch has something >> like >> > namespace fst { >> > typedef int32 ::int32; >> > } >> > >> > Doping this, the lookup works fine even under the ms c++. >> > To me, this is optimal solution as we have to patch the openfst >> anyway >> > (and my change wont break any code). >> > You can.have a look ať the openfstwin-1.3.3.patch in tools/extras. >> > I am open to any suggestion or general discussion on how this should >> > be made better. >> > Y. >> > >> > On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote: >> >> >> >> > Well, the build was not "painless" at all. In fact, the perl >> script >> >> > generated a solution with 600+ projects that simply failed to >> >> > build. VS was churning out dependencies on these, and crashed in >> >> > about 10 minutes of just sitting there with a 100% CPU use. Not a >> >> > single file was compiled, so I think it was just autogenerating >> dependencies at this point. >> >> >> >> Build systems on Windows are pretty broken. I think in Microsoft >> >> they use some other system, not the one used in VS, which is not >> >> publicly released. >> >> >> >> > I did not try to build from the command line though. Am I >> >> > understanding it would compile? >> >> >> >> No, not everything would compile. Sometimes the VS compiler just >> crashes. >> >> >> >> > What I did not like about the existing system is that I could not >> >> > plug in CUDA or intel compiler. It is extremely rigid in the >> option >> >> > part, and to change compiler options you are most likely to change >> >> > the perl code that generates the project files, or modify the >> >> > different MSBuild include files (called "property sheets" in this >> >> > context) that are interplaying quite non-trivially. No, I have >> >> > spent a few days on the build system not for a love of tinkering >> >> > with MSBuils at all! :) >> >> >> >> What we committed was just a hack to try to get something working. >> >> IIRC we just looked at the build files generated by VS to try to >> >> guess what the format of those files was supposed to be; I'm not >> sure >> >> that they are really intended to be human readable/writable (unless >> >> that human really loves XML). >> >> >> >> > Anyway, you can look at it at >> >> > https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I have >> >> > not updated the branch in a while) If you think this is not an >> >> > acceptable solution, I'm just dropping the ball, no offence taken, >> >> > naturally. I can maintain this as an "unofficial port" for a >> while. >> >> > In any case, build is the least problem, as Dan has pointed out >> already... >> >> > >> >> > The biggest (in the number of changed lines) changes I had to make >> >> > were in the namespace using declarations, because of conflicts >> >> > between the types >> >> > int32 and friends from different namespaces. I ended up reading >> the >> >> > C++ standard to understand whether gcc, icl or msvc is "correct" >> in >> >> > different cases they are complaining about, and the standard >> >> > appears not to define any behavior there. These changes I would >> >> > prefer accepted into the mainline of development, because they are >> harder to maintain in a fork. >> >> >> >> In any case where you have to do something like typedef kaldi::int32 >> >> int32, we should definitely get this committed- talk to Yenda. >> >> Actually, this is really a bug in OpenFST which they haven't fixed >> >> yet. There is a "proper" POSIX way to get types like int32, which >> we >> >> use in Kaldi, but in OpenFst they do it in a different, ad-hoc way >> >> which sometimes generates different types (e.g. on a system where >> int >> >> and long int are both 32-bit). So the Kaldi int32 and the OpenFst >> >> int32 end up being different, incompatible types. >> >> >> >> Dan >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Jan Trmal [mailto:jt...@gm...] >> >> >> Sent: 2015-05-11 0201 >> >> >> To: Dan Povey >> >> >> Cc: Kirill Katsnelson; kal...@li...; >> >> >> kaldi- us...@li...; 洪孝宗 >> >> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013 >> >> >> >> >> >> Guys, the migration to git is "unofficially" done -- unless we >> >> >> find some problems with it, the repo (https://github.com/kaldi- >> >> >> asr/kaldi.git) will stay as it is now. >> >> >> >> >> >> Kirill, there is no reason why wait. We should start working on >> it. >> >> >> I propose you could first send the Kaldi code patches -- I >> >> >> actually worked on this and I'm able to compile Kaldi, so this >> >> >> should be quite straightforward, provided you will generate the >> diff against the HEAD. >> >> >> >> >> >> Then we can start looking at the "build system". I understand >> >> >> your reasons and I think they might be legit. My feeling is, >> >> >> however, that a lot of people are not using MSBuild and will >> >> >> expect the MSVC solution, just because this is how they usually >> >> >> work. I haven't tested it, but you should be able to use the >> >> >> current SLN to build the binaries from command line -- that >> should >> >> >> be completely painless -- but again, I haven't tested it. >> >> >> y. >> >> >> >> >> >> >> >> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey <dp...@gm...> >> wrote: >> >> >> >> >> >> >> >> >> >> To the extent that your patches are simple fixes and >> >> >> minor changes to >> >> >> >> the code, I think we could apply them. Perhaps you >> could >> >> >> work with >> >> >> >> Yenda to get your changes checked? >> >> >> > >> >> >> > Easy enough, and as easy to hold till the migration is >> done. >> >> >> Was there a change in the plans? >> >> >> >> >> >> Not really a change in the plans, but we don't have a >> definite >> >> >> timeline for migrating to git, and it could be that we'll >> >> >> keep the svn >> >> >> as upstream for a while. Your changes seem reasonable, but >> >> >> I think it >> >> >> would be better to get things started now rather than >> later. >> >> >> The >> >> >> git/svn issues should not be that hard. Just start sending >> >> >> patches to >> >> >> Yenda and we'll handle your changes bit by bit. >> >> >> Dan >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> If you update your git repo to >> >> >> >> point to the current code, then a patch should be >> >> >> applicable by the >> >> >> >> program "patch" to the svn repo too. >> >> >> > >> >> >> > There are many changes, and I certainly want to split the >> >> >> patch so it is readable. One megapatch is not reviewable. >> >> >> > >> >> >> >> Regarding your build approach, you could send me and >> >> >> Yenda some details >> >> >> >> about how you did it, and we could consider whether to >> >> >> support that. >> >> >> > >> >> >> > There's a Powershell script that takes information from >> >> >> every src/*/Makefile into a simple declarative MSBuild script >> >> >> $dirname.kwproj, and a top-level MSBuild "makefile" that drives >> >> >> the whole thing. A little bit more complex than that to allow for >> >> >> user- defined options, but generally this is it. This supports >> >> >> building libraries, tools, tests and running the tests with >> >> >> command line switches. The whole thing pretty much mimics a linux >> >> >> make process but using MS tools. >> >> >> > >> >> >> >> I don't think it makes sense to try to maintain a >> >> >> parallel >> >> >> "windows- >> >> >> >> compatible" version of the scripts, if there are larger >> >> >> changes >> >> >> >> required there. >> >> >> > >> >> >> > I was targeting for no changes at all. There maybe a few >> >> >> very small patches that supposed not to break compatibility. >> >> >> > >> >> >> >> Anyway you depend on cygwin for scripting, and the set >> >> >> >> of people who want to run cygwin and build with MSVC is >> >> >> probably >> >> >> >> limited enough that I don't think it makes sense for us >> >> >> to try to >> >> >> >> support it. >> >> >> > >> >> >> > This is not as simple a choice as it seems at first. Alex >> >> >> Hung just posted a trick to build CUDA under Cygwin; before he >> did >> >> >> I thought it was not possible. MKL is another story. I would >> >> >> rather build under native Windows than try to pull this monster >> >> >> into the Cygwin build environment. >> >> >> > >> >> >> > -kkm >> >> >> > >> >> >> >> >> >> >> >> > |
|
From: Kirill K. <kir...@sm...> - 2015-05-11 21:50:23
|
I thought it was but this really appears to be a grey area in the standard. But indeed, from the practical standpoint, I think the best thing to do is just make all compilers happy. I can figure out if this is really undefined C++ later, if there is a theoretical interest.
-kkm
> -----Original Message-----
> From: Daniel Povey [mailto:dp...@gm...]
> Sent: 2015-05-11 1444
> To: Jan Trmal
> Cc: Kirill Katsnelson; kal...@li...; kaldi-
> dev...@li...; 洪孝宗
> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013
>
> OK fine.
> I'm pretty sure this is a bug in MSVC, that the namespace lookup for a
> templated function happens in the context in which the template is
> evaluated (as opposed to where it was defined). But it makes sense to
> patch it anyway.
> Dan
>
>
> On Mon, May 11, 2015 at 2:09 PM, Jan Trmal <jt...@gm...> wrote:
> > Ok, I will have a.look tmrw. I think I've resolved the types issue
> > (last one you mentioned). I generated the patch for openfst, that
> > defines the int types within the openfst namespace - originally they
> > exist on.the highest scope (i.e. ::int32) The patch has something
> like
> > namespace fst {
> > typedef int32 ::int32;
> > }
> >
> > Doping this, the lookup works fine even under the ms c++.
> > To me, this is optimal solution as we have to patch the openfst
> anyway
> > (and my change wont break any code).
> > You can.have a look ať the openfstwin-1.3.3.patch in tools/extras.
> > I am open to any suggestion or general discussion on how this should
> > be made better.
> > Y.
> >
> > On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote:
> >>
> >> > Well, the build was not "painless" at all. In fact, the perl
> script
> >> > generated a solution with 600+ projects that simply failed to
> >> > build. VS was churning out dependencies on these, and crashed in
> >> > about 10 minutes of just sitting there with a 100% CPU use. Not a
> >> > single file was compiled, so I think it was just autogenerating
> dependencies at this point.
> >>
> >> Build systems on Windows are pretty broken. I think in Microsoft
> >> they use some other system, not the one used in VS, which is not
> >> publicly released.
> >>
> >> > I did not try to build from the command line though. Am I
> >> > understanding it would compile?
> >>
> >> No, not everything would compile. Sometimes the VS compiler just
> crashes.
> >>
> >> > What I did not like about the existing system is that I could not
> >> > plug in CUDA or intel compiler. It is extremely rigid in the
> option
> >> > part, and to change compiler options you are most likely to change
> >> > the perl code that generates the project files, or modify the
> >> > different MSBuild include files (called "property sheets" in this
> >> > context) that are interplaying quite non-trivially. No, I have
> >> > spent a few days on the build system not for a love of tinkering
> >> > with MSBuils at all! :)
> >>
> >> What we committed was just a hack to try to get something working.
> >> IIRC we just looked at the build files generated by VS to try to
> >> guess what the format of those files was supposed to be; I'm not
> sure
> >> that they are really intended to be human readable/writable (unless
> >> that human really loves XML).
> >>
> >> > Anyway, you can look at it at
> >> > https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I have
> >> > not updated the branch in a while) If you think this is not an
> >> > acceptable solution, I'm just dropping the ball, no offence taken,
> >> > naturally. I can maintain this as an "unofficial port" for a
> while.
> >> > In any case, build is the least problem, as Dan has pointed out
> already...
> >> >
> >> > The biggest (in the number of changed lines) changes I had to make
> >> > were in the namespace using declarations, because of conflicts
> >> > between the types
> >> > int32 and friends from different namespaces. I ended up reading
> the
> >> > C++ standard to understand whether gcc, icl or msvc is "correct"
> in
> >> > different cases they are complaining about, and the standard
> >> > appears not to define any behavior there. These changes I would
> >> > prefer accepted into the mainline of development, because they are
> harder to maintain in a fork.
> >>
> >> In any case where you have to do something like typedef kaldi::int32
> >> int32, we should definitely get this committed- talk to Yenda.
> >> Actually, this is really a bug in OpenFST which they haven't fixed
> >> yet. There is a "proper" POSIX way to get types like int32, which
> we
> >> use in Kaldi, but in OpenFst they do it in a different, ad-hoc way
> >> which sometimes generates different types (e.g. on a system where
> int
> >> and long int are both 32-bit). So the Kaldi int32 and the OpenFst
> >> int32 end up being different, incompatible types.
> >>
> >> Dan
> >>
> >>
> >> >> -----Original Message-----
> >> >> From: Jan Trmal [mailto:jt...@gm...]
> >> >> Sent: 2015-05-11 0201
> >> >> To: Dan Povey
> >> >> Cc: Kirill Katsnelson; kal...@li...;
> >> >> kaldi- us...@li...; 洪孝宗
> >> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013
> >> >>
> >> >> Guys, the migration to git is "unofficially" done -- unless we
> >> >> find some problems with it, the repo (https://github.com/kaldi-
> >> >> asr/kaldi.git) will stay as it is now.
> >> >>
> >> >> Kirill, there is no reason why wait. We should start working on
> it.
> >> >> I propose you could first send the Kaldi code patches -- I
> >> >> actually worked on this and I'm able to compile Kaldi, so this
> >> >> should be quite straightforward, provided you will generate the
> diff against the HEAD.
> >> >>
> >> >> Then we can start looking at the "build system". I understand
> >> >> your reasons and I think they might be legit. My feeling is,
> >> >> however, that a lot of people are not using MSBuild and will
> >> >> expect the MSVC solution, just because this is how they usually
> >> >> work. I haven't tested it, but you should be able to use the
> >> >> current SLN to build the binaries from command line -- that
> should
> >> >> be completely painless -- but again, I haven't tested it.
> >> >> y.
> >> >>
> >> >>
> >> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey <dp...@gm...>
> wrote:
> >> >>
> >> >>
> >> >> >> To the extent that your patches are simple fixes and
> >> >> minor changes to
> >> >> >> the code, I think we could apply them. Perhaps you
> could
> >> >> work with
> >> >> >> Yenda to get your changes checked?
> >> >> >
> >> >> > Easy enough, and as easy to hold till the migration is
> done.
> >> >> Was there a change in the plans?
> >> >>
> >> >> Not really a change in the plans, but we don't have a
> definite
> >> >> timeline for migrating to git, and it could be that we'll
> >> >> keep the svn
> >> >> as upstream for a while. Your changes seem reasonable, but
> >> >> I think it
> >> >> would be better to get things started now rather than
> later.
> >> >> The
> >> >> git/svn issues should not be that hard. Just start sending
> >> >> patches to
> >> >> Yenda and we'll handle your changes bit by bit.
> >> >> Dan
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> >> If you update your git repo to
> >> >> >> point to the current code, then a patch should be
> >> >> applicable by the
> >> >> >> program "patch" to the svn repo too.
> >> >> >
> >> >> > There are many changes, and I certainly want to split the
> >> >> patch so it is readable. One megapatch is not reviewable.
> >> >> >
> >> >> >> Regarding your build approach, you could send me and
> >> >> Yenda some details
> >> >> >> about how you did it, and we could consider whether to
> >> >> support that.
> >> >> >
> >> >> > There's a Powershell script that takes information from
> >> >> every src/*/Makefile into a simple declarative MSBuild script
> >> >> $dirname.kwproj, and a top-level MSBuild "makefile" that drives
> >> >> the whole thing. A little bit more complex than that to allow for
> >> >> user- defined options, but generally this is it. This supports
> >> >> building libraries, tools, tests and running the tests with
> >> >> command line switches. The whole thing pretty much mimics a linux
> >> >> make process but using MS tools.
> >> >> >
> >> >> >> I don't think it makes sense to try to maintain a
> >> >> parallel
> >> >> "windows-
> >> >> >> compatible" version of the scripts, if there are larger
> >> >> changes
> >> >> >> required there.
> >> >> >
> >> >> > I was targeting for no changes at all. There maybe a few
> >> >> very small patches that supposed not to break compatibility.
> >> >> >
> >> >> >> Anyway you depend on cygwin for scripting, and the set
> >> >> >> of people who want to run cygwin and build with MSVC is
> >> >> probably
> >> >> >> limited enough that I don't think it makes sense for us
> >> >> to try to
> >> >> >> support it.
> >> >> >
> >> >> > This is not as simple a choice as it seems at first. Alex
> >> >> Hung just posted a trick to build CUDA under Cygwin; before he
> did
> >> >> I thought it was not possible. MKL is another story. I would
> >> >> rather build under native Windows than try to pull this monster
> >> >> into the Cygwin build environment.
> >> >> >
> >> >> > -kkm
> >> >> >
> >> >>
> >> >>
> >> >
|
|
From: Kirill K. <kir...@sm...> - 2015-05-11 21:45:32
|
> -----Original Message----- > From: Jan Trmal [mailto:jt...@gm...] > Sent: 2015-05-11 0201 > > Kirill, there is no reason why wait. We should start working on it. > I propose you could first send the Kaldi code patches -- I actually > worked on this and I'm able to compile Kaldi, so this should be quite > straightforward, provided you will generate the diff against the HEAD. Sorry, did not address this part in the previous message. SGTM, I'll replay my repo changes on top of a github fork, and then we can start from there. I'm sure to hit a couple snags doing that, so give me a few days. Did you look at https://github.com/workflow-demo-org/workflow-demo/wiki/GitHub-pull-request-based-workflow? Too basic, too complex, any help from this at all? -kkm |
|
From: Daniel P. <dp...@gm...> - 2015-05-11 21:44:35
|
OK fine.
I'm pretty sure this is a bug in MSVC, that the namespace lookup for a
templated function happens in the context in which the template is
evaluated (as opposed to where it was defined). But it makes sense to
patch it anyway.
Dan
On Mon, May 11, 2015 at 2:09 PM, Jan Trmal <jt...@gm...> wrote:
> Ok, I will have a.look tmrw. I think I've resolved the types issue (last one
> you mentioned). I generated the patch for openfst, that defines the int
> types within the openfst namespace - originally they exist on.the highest
> scope (i.e. ::int32)
> The patch has something like
> namespace fst {
> typedef int32 ::int32;
> }
>
> Doping this, the lookup works fine even under the ms c++.
> To me, this is optimal solution as we have to patch the openfst anyway (and
> my change wont break any code).
> You can.have a look ať the openfstwin-1.3.3.patch in tools/extras.
> I am open to any suggestion or general discussion on how this should be made
> better.
> Y.
>
> On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote:
>>
>> > Well, the build was not "painless" at all. In fact, the perl script
>> > generated a solution with 600+ projects that simply failed to build. VS was
>> > churning out dependencies on these, and crashed in about 10 minutes of just
>> > sitting there with a 100% CPU use. Not a single file was compiled, so I
>> > think it was just autogenerating dependencies at this point.
>>
>> Build systems on Windows are pretty broken. I think in Microsoft they
>> use some other system, not the one used in VS, which is not publicly
>> released.
>>
>> > I did not try to build from the command line though. Am I understanding
>> > it would compile?
>>
>> No, not everything would compile. Sometimes the VS compiler just crashes.
>>
>> > What I did not like about the existing system is that I could not plug
>> > in CUDA or intel compiler. It is extremely rigid in the option part, and to
>> > change compiler options you are most likely to change the perl code that
>> > generates the project files, or modify the different MSBuild include files
>> > (called "property sheets" in this context) that are interplaying quite
>> > non-trivially. No, I have spent a few days on the build system not for a
>> > love of tinkering with MSBuils at all! :)
>>
>> What we committed was just a hack to try to get something working.
>> IIRC we just looked at the build files generated by VS to try to guess
>> what the format of those files was supposed to be; I'm not sure that
>> they are really intended to be human readable/writable (unless that
>> human really loves XML).
>>
>> > Anyway, you can look at it at
>> > https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I have not
>> > updated the branch in a while) If you think this is not an acceptable
>> > solution, I'm just dropping the ball, no offence taken, naturally. I can
>> > maintain this as an "unofficial port" for a while. In any case, build is the
>> > least problem, as Dan has pointed out already...
>> >
>> > The biggest (in the number of changed lines) changes I had to make were
>> > in the namespace using declarations, because of conflicts between the types
>> > int32 and friends from different namespaces. I ended up reading the C++
>> > standard to understand whether gcc, icl or msvc is "correct" in different
>> > cases they are complaining about, and the standard appears not to define any
>> > behavior there. These changes I would prefer accepted into the mainline of
>> > development, because they are harder to maintain in a fork.
>>
>> In any case where you have to do something like typedef kaldi::int32
>> int32, we should definitely get this committed- talk to Yenda.
>> Actually, this is really a bug in OpenFST which they haven't fixed
>> yet. There is a "proper" POSIX way to get types like int32, which we
>> use in Kaldi, but in OpenFst they do it in a different, ad-hoc way
>> which sometimes generates different types (e.g. on a system where int
>> and long int are both 32-bit). So the Kaldi int32 and the OpenFst
>> int32 end up being different, incompatible types.
>>
>> Dan
>>
>>
>> >> -----Original Message-----
>> >> From: Jan Trmal [mailto:jt...@gm...]
>> >> Sent: 2015-05-11 0201
>> >> To: Dan Povey
>> >> Cc: Kirill Katsnelson; kal...@li...; kaldi-
>> >> us...@li...; 洪孝宗
>> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013
>> >>
>> >> Guys, the migration to git is "unofficially" done -- unless we find
>> >> some problems with it, the repo (https://github.com/kaldi-
>> >> asr/kaldi.git) will stay as it is now.
>> >>
>> >> Kirill, there is no reason why wait. We should start working on it.
>> >> I propose you could first send the Kaldi code patches -- I actually
>> >> worked on this and I'm able to compile Kaldi, so this should be quite
>> >> straightforward, provided you will generate the diff against the HEAD.
>> >>
>> >> Then we can start looking at the "build system". I understand your
>> >> reasons and I think they might be legit. My feeling is, however, that a
>> >> lot of people are not using MSBuild and will expect the MSVC solution,
>> >> just because this is how they usually work. I haven't tested it, but
>> >> you should be able to use the current SLN to build the binaries from
>> >> command line -- that should be completely painless -- but again, I
>> >> haven't tested it.
>> >> y.
>> >>
>> >>
>> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey <dp...@gm...> wrote:
>> >>
>> >>
>> >> >> To the extent that your patches are simple fixes and minor
>> >> changes to
>> >> >> the code, I think we could apply them. Perhaps you could work
>> >> with
>> >> >> Yenda to get your changes checked?
>> >> >
>> >> > Easy enough, and as easy to hold till the migration is done.
>> >> Was there a change in the plans?
>> >>
>> >> Not really a change in the plans, but we don't have a definite
>> >> timeline for migrating to git, and it could be that we'll keep
>> >> the svn
>> >> as upstream for a while. Your changes seem reasonable, but I
>> >> think it
>> >> would be better to get things started now rather than later.
>> >> The
>> >> git/svn issues should not be that hard. Just start sending
>> >> patches to
>> >> Yenda and we'll handle your changes bit by bit.
>> >> Dan
>> >>
>> >>
>> >>
>> >> >
>> >> >> If you update your git repo to
>> >> >> point to the current code, then a patch should be applicable
>> >> by the
>> >> >> program "patch" to the svn repo too.
>> >> >
>> >> > There are many changes, and I certainly want to split the patch
>> >> so it is readable. One megapatch is not reviewable.
>> >> >
>> >> >> Regarding your build approach, you could send me and Yenda
>> >> some details
>> >> >> about how you did it, and we could consider whether to support
>> >> that.
>> >> >
>> >> > There's a Powershell script that takes information from every
>> >> src/*/Makefile into a simple declarative MSBuild script
>> >> $dirname.kwproj, and a top-level MSBuild "makefile" that drives the
>> >> whole thing. A little bit more complex than that to allow for user-
>> >> defined options, but generally this is it. This supports building
>> >> libraries, tools, tests and running the tests with command line
>> >> switches. The whole thing pretty much mimics a linux make process but
>> >> using MS tools.
>> >> >
>> >> >> I don't think it makes sense to try to maintain a parallel
>> >> "windows-
>> >> >> compatible" version of the scripts, if there are larger
>> >> changes
>> >> >> required there.
>> >> >
>> >> > I was targeting for no changes at all. There maybe a few very
>> >> small patches that supposed not to break compatibility.
>> >> >
>> >> >> Anyway you depend on cygwin for scripting, and the set
>> >> >> of people who want to run cygwin and build with MSVC is
>> >> probably
>> >> >> limited enough that I don't think it makes sense for us to try
>> >> to
>> >> >> support it.
>> >> >
>> >> > This is not as simple a choice as it seems at first. Alex Hung
>> >> just posted a trick to build CUDA under Cygwin; before he did I thought
>> >> it was not possible. MKL is another story. I would rather build under
>> >> native Windows than try to pull this monster into the Cygwin build
>> >> environment.
>> >> >
>> >> > -kkm
>> >> >
>> >>
>> >>
>> >
|
|
From: Jan T. <jt...@gm...> - 2015-05-11 21:09:49
|
Ok, I will have a.look tmrw. I think I've resolved the types issue (last
one you mentioned). I generated the patch for openfst, that defines the int
types within the openfst namespace - originally they exist on.the highest
scope (i.e. ::int32)
The patch has something like
namespace fst {
typedef int32 ::int32;
}
Doping this, the lookup works fine even under the ms c++.
To me, this is optimal solution as we have to patch the openfst anyway (and
my change wont break any code).
You can.have a look ať the openfstwin-1.3.3.patch in tools/extras.
I am open to <http://am.open.to/> any suggestion or general discussion on
how this should be made better.
Y.
On May 11, 2015 9:03 PM, "Daniel Povey" <dp...@gm...> wrote:
> > Well, the build was not "painless" at all. In fact, the perl script
> generated a solution with 600+ projects that simply failed to build. VS was
> churning out dependencies on these, and crashed in about 10 minutes of just
> sitting there with a 100% CPU use. Not a single file was compiled, so I
> think it was just autogenerating dependencies at this point.
>
> Build systems on Windows are pretty broken. I think in Microsoft they
> use some other system, not the one used in VS, which is not publicly
> released.
>
> > I did not try to build from the command line though. Am I understanding
> it would compile?
>
> No, not everything would compile. Sometimes the VS compiler just crashes.
>
> > What I did not like about the existing system is that I could not plug
> in CUDA or intel compiler. It is extremely rigid in the option part, and to
> change compiler options you are most likely to change the perl code that
> generates the project files, or modify the different MSBuild include files
> (called "property sheets" in this context) that are interplaying quite
> non-trivially. No, I have spent a few days on the build system not for a
> love of tinkering with MSBuils at all! :)
>
> What we committed was just a hack to try to get something working.
> IIRC we just looked at the build files generated by VS to try to guess
> what the format of those files was supposed to be; I'm not sure that
> they are really intended to be human readable/writable (unless that
> human really loves XML).
>
> > Anyway, you can look at it at
> https://github.com/kkm000/kaldi/tree/winbuild/msbuild. (NB I have not
> updated the branch in a while) If you think this is not an acceptable
> solution, I'm just dropping the ball, no offence taken, naturally. I can
> maintain this as an "unofficial port" for a while. In any case, build is
> the least problem, as Dan has pointed out already...
> >
> > The biggest (in the number of changed lines) changes I had to make were
> in the namespace using declarations, because of conflicts between the types
> int32 and friends from different namespaces. I ended up reading the C++
> standard to understand whether gcc, icl or msvc is "correct" in different
> cases they are complaining about, and the standard appears not to define
> any behavior there. These changes I would prefer accepted into the mainline
> of development, because they are harder to maintain in a fork.
>
> In any case where you have to do something like typedef kaldi::int32
> int32, we should definitely get this committed- talk to Yenda.
> Actually, this is really a bug in OpenFST which they haven't fixed
> yet. There is a "proper" POSIX way to get types like int32, which we
> use in Kaldi, but in OpenFst they do it in a different, ad-hoc way
> which sometimes generates different types (e.g. on a system where int
> and long int are both 32-bit). So the Kaldi int32 and the OpenFst
> int32 end up being different, incompatible types.
>
> Dan
>
>
> >> -----Original Message-----
> >> From: Jan Trmal [mailto:jt...@gm...]
> >> Sent: 2015-05-11 0201
> >> To: Dan Povey
> >> Cc: Kirill Katsnelson; kal...@li...; kaldi-
> >> us...@li...; 洪孝宗
> >> Subject: Re: [Kaldi-users] Kaldi compiles now under VS 2013
> >>
> >> Guys, the migration to git is "unofficially" done -- unless we find
> >> some problems with it, the repo (https://github.com/kaldi-
> >> asr/kaldi.git) will stay as it is now.
> >>
> >> Kirill, there is no reason why wait. We should start working on it.
> >> I propose you could first send the Kaldi code patches -- I actually
> >> worked on this and I'm able to compile Kaldi, so this should be quite
> >> straightforward, provided you will generate the diff against the HEAD.
> >>
> >> Then we can start looking at the "build system". I understand your
> >> reasons and I think they might be legit. My feeling is, however, that a
> >> lot of people are not using MSBuild and will expect the MSVC solution,
> >> just because this is how they usually work. I haven't tested it, but
> >> you should be able to use the current SLN to build the binaries from
> >> command line -- that should be completely painless -- but again, I
> >> haven't tested it.
> >> y.
> >>
> >>
> >> On Thu, May 7, 2015 at 10:53 PM, Daniel Povey <dp...@gm...> wrote:
> >>
> >>
> >> >> To the extent that your patches are simple fixes and minor
> >> changes to
> >> >> the code, I think we could apply them. Perhaps you could work
> >> with
> >> >> Yenda to get your changes checked?
> >> >
> >> > Easy enough, and as easy to hold till the migration is done.
> >> Was there a change in the plans?
> >>
> >> Not really a change in the plans, but we don't have a definite
> >> timeline for migrating to git, and it could be that we'll keep
> >> the svn
> >> as upstream for a while. Your changes seem reasonable, but I
> >> think it
> >> would be better to get things started now rather than later.
> >> The
> >> git/svn issues should not be that hard. Just start sending
> >> patches to
> >> Yenda and we'll handle your changes bit by bit.
> >> Dan
> >>
> >>
> >>
> >> >
> >> >> If you update your git repo to
> >> >> point to the current code, then a patch should be applicable
> >> by the
> >> >> program "patch" to the svn repo too.
> >> >
> >> > There are many changes, and I certainly want to split the patch
> >> so it is readable. One megapatch is not reviewable.
> >> >
> >> >> Regarding your build approach, you could send me and Yenda
> >> some details
> >> >> about how you did it, and we could consider whether to support
> >> that.
> >> >
> >> > There's a Powershell script that takes information from every
> >> src/*/Makefile into a simple declarative MSBuild script
> >> $dirname.kwproj, and a top-level MSBuild "makefile" that drives the
> >> whole thing. A little bit more complex than that to allow for user-
> >> defined options, but generally this is it. This supports building
> >> libraries, tools, tests and running the tests with command line
> >> switches. The whole thing pretty much mimics a linux make process but
> >> using MS tools.
> >> >
> >> >> I don't think it makes sense to try to maintain a parallel
> >> "windows-
> >> >> compatible" version of the scripts, if there are larger
> >> changes
> >> >> required there.
> >> >
> >> > I was targeting for no changes at all. There maybe a few very
> >> small patches that supposed not to break compatibility.
> >> >
> >> >> Anyway you depend on cygwin for scripting, and the set
> >> >> of people who want to run cygwin and build with MSVC is
> >> probably
> >> >> limited enough that I don't think it makes sense for us to try
> >> to
> >> >> support it.
> >> >
> >> > This is not as simple a choice as it seems at first. Alex Hung
> >> just posted a trick to build CUDA under Cygwin; before he did I thought
> >> it was not possible. MKL is another story. I would rather build under
> >> native Windows than try to pull this monster into the Cygwin build
> >> environment.
> >> >
> >> > -kkm
> >> >
> >>
> >>
> >
>
|
|
From: Kirill K. <kir...@sm...> - 2015-05-11 19:39:04
|
> -----Original Message----- > From: Daniel Povey [mailto:dp...@gm...] > Sent: 2015-05-11 1158 > > > Many recipes use per-speaker adapted features. I am working in a > field where we rarely see the same speaker again. To be able to compare > apples to apples, I want to avoid the dependency on per-speaker > adaptation. So one thing I want to do is drop utt <-> spk maps and use > global LDA and per-sentence fMLLR adaptation only. > > fMLLR applied globally does not really make sense, as there would be no > adaptation going on. I recommend to make the utt<->spk maps one-to-one > (make the utterance-id and speaker-id identical). You can see whether > fMLLR helps, and drop it if not; or try basis fMLLR. Right, that was what I meant by per-utterance fMMLR. I mistyped "per-sentence," too much NLP recently. :) > (Note: by > default we don't enable variance normalization, so CMVN is a bit of a > misnomer). Thanks for pointing this out. I did not understand the V part was not there. -kkm |
1 message has been excluded from this view by a project administrator.
