You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(1) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(13) |
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
(14) |
Nov
(16) |
Dec
(1) |
2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(21) |
May
(27) |
Jun
(11) |
Jul
(11) |
Aug
(21) |
Sep
(39) |
Oct
(17) |
Nov
(39) |
Dec
(28) |
2014 |
Jan
(36) |
Feb
(30) |
Mar
(35) |
Apr
(17) |
May
(22) |
Jun
(28) |
Jul
(23) |
Aug
(41) |
Sep
(17) |
Oct
(10) |
Nov
(22) |
Dec
(56) |
2015 |
Jan
(30) |
Feb
(32) |
Mar
(37) |
Apr
(28) |
May
(79) |
Jun
(18) |
Jul
(35) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: <jen...@a2...> - 2014-07-18 11:20:57
|
Kaldi - Build # 606 - Fixed: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-17 15:55:38
|
Kaldi - Build # 605 - Failure: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-11 18:44:15
|
Kaldi - Build # 594 - Fixed: See the build log in attachment for the details. |
From: Augusto H. H. <au...@li...> - 2014-07-07 19:35:13
|
Wow, thanks for the prompt response! On Jul 7, 2014, at 16:34 , Daniel Povey <dp...@gm...> wrote: > OK, I found the bug and fixed it. > Dan > > > > On Mon, Jul 7, 2014 at 3:14 PM, Augusto Henrique Hentz <au...@li...> wrote: > Hi Dan, it is the code in trunk, latest revision (4143). > > On Jul 7, 2014, at 16:01 , Daniel Povey <dp...@gm...> wrote: > > > Are you using the code in trunk? If so, what revision? > > Dan > > > > > > > > On Mon, Jul 7, 2014 at 2:19 PM, Augusto Henrique Hentz <au...@li...> wrote: > > Hello all, > > > > When using the gmm-latgen-biglm-faster, I get the following warning: > > > > WARNING (~HashList():util/hash-list-inl.h:115) Possible memory leak: 1815 != 2048 > > > > for every utterance. I checked the LatticeFasterDecoder class, and this is the part that clears the HashList > > > > void LatticeFasterDecoder::DeleteElems(Elem *list) { > > for (Elem *e = list, *e_tail; e != NULL; e = e_tail) { > > // Token::TokenDelete(e->val); > > e_tail = e->tail; > > toks_.Delete(e); > > } > > } > > > > this method is called as > > > > DeleteElems(toks_.Clear()); > > > > The elements are deleted from the HashList (toks_.Delete(e)), so there should be no leak. Also, any ideas why the `Token::TokenDelete(e->val)` statement is commented out? > > > > Thanks > > > > -- > > Augusto Henrique Hentz > > au...@li... > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Open source business process management suite built on Java and Eclipse > > Turn processes into business applications with Bonita BPM Community Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > -- > Augusto Henrique Hentz > au...@li... > > > > > -- Augusto Henrique Hentz au...@li... |
From: Daniel P. <dp...@gm...> - 2014-07-07 19:34:09
|
OK, I found the bug and fixed it. Dan On Mon, Jul 7, 2014 at 3:14 PM, Augusto Henrique Hentz < au...@li...> wrote: > Hi Dan, it is the code in trunk, latest revision (4143). > > On Jul 7, 2014, at 16:01 , Daniel Povey <dp...@gm...> wrote: > > > Are you using the code in trunk? If so, what revision? > > Dan > > > > > > > > On Mon, Jul 7, 2014 at 2:19 PM, Augusto Henrique Hentz < > au...@li...> wrote: > > Hello all, > > > > When using the gmm-latgen-biglm-faster, I get the following warning: > > > > WARNING (~HashList():util/hash-list-inl.h:115) Possible memory leak: > 1815 != 2048 > > > > for every utterance. I checked the LatticeFasterDecoder class, and this > is the part that clears the HashList > > > > void LatticeFasterDecoder::DeleteElems(Elem *list) { > > for (Elem *e = list, *e_tail; e != NULL; e = e_tail) { > > // Token::TokenDelete(e->val); > > e_tail = e->tail; > > toks_.Delete(e); > > } > > } > > > > this method is called as > > > > DeleteElems(toks_.Clear()); > > > > The elements are deleted from the HashList (toks_.Delete(e)), so there > should be no leak. Also, any ideas why the `Token::TokenDelete(e->val)` > statement is commented out? > > > > Thanks > > > > -- > > Augusto Henrique Hentz > > au...@li... > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Open source business process management suite built on Java and Eclipse > > Turn processes into business applications with Bonita BPM Community > Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > -- > Augusto Henrique Hentz > au...@li... > > > > > |
From: Daniel P. <dp...@gm...> - 2014-07-07 19:01:29
|
Are you using the code in trunk? If so, what revision? Dan On Mon, Jul 7, 2014 at 2:19 PM, Augusto Henrique Hentz < au...@li...> wrote: > Hello all, > > When using the gmm-latgen-biglm-faster, I get the following warning: > > WARNING (~HashList():util/hash-list-inl.h:115) Possible memory leak: 1815 > != 2048 > > for every utterance. I checked the LatticeFasterDecoder class, and this is > the part that clears the HashList > > void LatticeFasterDecoder::DeleteElems(Elem *list) { > for (Elem *e = list, *e_tail; e != NULL; e = e_tail) { > // Token::TokenDelete(e->val); > e_tail = e->tail; > toks_.Delete(e); > } > } > > this method is called as > > DeleteElems(toks_.Clear()); > > The elements are deleted from the HashList (toks_.Delete(e)), so there > should be no leak. Also, any ideas why the `Token::TokenDelete(e->val)` > statement is commented out? > > Thanks > > -- > Augusto Henrique Hentz > au...@li... > > > > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > |
From: Augusto H. H. <au...@li...> - 2014-07-07 18:45:34
|
Hello all, When using the gmm-latgen-biglm-faster, I get the following warning: WARNING (~HashList():util/hash-list-inl.h:115) Possible memory leak: 1815 != 2048 for every utterance. I checked the LatticeFasterDecoder class, and this is the part that clears the HashList void LatticeFasterDecoder::DeleteElems(Elem *list) { for (Elem *e = list, *e_tail; e != NULL; e = e_tail) { // Token::TokenDelete(e->val); e_tail = e->tail; toks_.Delete(e); } } this method is called as DeleteElems(toks_.Clear()); The elements are deleted from the HashList (toks_.Delete(e)), so there should be no leak. Also, any ideas why the `Token::TokenDelete(e->val)` statement is commented out? Thanks -- Augusto Henrique Hentz au...@li... |
From: <jen...@a2...> - 2014-07-07 16:49:37
|
Kaldi - Build # 586 - Fixed: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-06 01:49:35
|
Kaldi - Build # 584 - Fixed: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-04 05:29:29
|
Kaldi - Build # 583 - Still Failing: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-03 23:28:53
|
Kaldi - Build # 581 - Fixed: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-03 21:01:53
|
Kaldi - Build # 582 - Failure: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-07-02 11:56:57
|
Kaldi - Build # 580 - Failure: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-06-30 07:48:45
|
Kaldi - Build # 576 - Fixed: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-06-30 06:18:45
|
Kaldi - Build # 575 - Failure: See the build log in attachment for the details. |
From: Arif K. <ife...@gm...> - 2014-06-26 14:57:55
|
Thanks a lot! Regards, Arif On 6/26/14 4:56 PM, Daniel Povey wrote: > No, you'll have to write one yourself. > Dan > > > > On Thu, Jun 26, 2014 at 5:17 AM, Arif Khan <ife...@gm... > <mailto:ife...@gm...>> wrote: > > Thanks Dan for your reply. > > I used the ali-to-phones module with --write-lengths options, > which gives me the time stamps of each phone like this: > > *01pc0201* 1 87 ; 172 12 ; 222 4 ; 237 12 ; 92 8 ; ................ > > As you said its not in ctm format, Is there any script/module > already for this to convert to a more human/usable format. > > > Best regards, > Arif > > > > > > On 6/24/14 7:08 PM, Daniel Povey wrote: >> The program ali-to-phones should give you the information that >> you need (when given the right options), but it won't be in a >> CTM-like format. >> Dan >> >> >> >> On Tue, Jun 24, 2014 at 1:06 PM, Arif Khan <ife...@gm... >> <mailto:ife...@gm...>> wrote: >> >> Hi, >> >> In the "steps/get_train_ctm.sh", we can get the word >> alignment which looks something like this: >> >> 018c021d 1 2.32 0.08 AN >> 018c021d 1 2.40 0.46 APPARENT >> 018c021d 1 2.86 0.59 SLOWDOWN >> 018c021d 1 3.45 0.11 IN >> 018c021d 1 3.56 0.58 ECONOMIC >> 018c021d 1 4.14 0.30 GROWTH >> >> Is there any recipe to get the phone alignment. i.e Beginning >> and End timing of phones in the same format as above. >> >> >> Best regards, >> Arif >> >> ------------------------------------------------------------------------------ >> Open source business process management suite built on Java >> and Eclipse >> Turn processes into business applications with Bonita BPM >> Community Edition >> Quickly connect people, data, and systems into organized >> workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> Kaldi-developers mailing list >> Kal...@li... >> <mailto:Kal...@li...> >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers >> >> > > |
From: Daniel P. <dp...@gm...> - 2014-06-26 14:56:30
|
No, you'll have to write one yourself. Dan On Thu, Jun 26, 2014 at 5:17 AM, Arif Khan <ife...@gm...> wrote: > Thanks Dan for your reply. > > I used the ali-to-phones module with --write-lengths options, which gives > me the time stamps of each phone like this: > > *01pc0201* 1 87 ; 172 12 ; 222 4 ; 237 12 ; 92 8 ; ................ > > As you said its not in ctm format, Is there any script/module already for > this to convert to a more human/usable format. > > > Best regards, > Arif > > > > > > On 6/24/14 7:08 PM, Daniel Povey wrote: > > The program ali-to-phones should give you the information that you need > (when given the right options), but it won't be in a CTM-like format. > Dan > > > > On Tue, Jun 24, 2014 at 1:06 PM, Arif Khan <ife...@gm...> wrote: > >> Hi, >> >> In the "steps/get_train_ctm.sh", we can get the word alignment which >> looks something like this: >> >> 018c021d 1 2.32 0.08 AN >> 018c021d 1 2.40 0.46 APPARENT >> 018c021d 1 2.86 0.59 SLOWDOWN >> 018c021d 1 3.45 0.11 IN >> 018c021d 1 3.56 0.58 ECONOMIC >> 018c021d 1 4.14 0.30 GROWTH >> >> Is there any recipe to get the phone alignment. i.e Beginning and End >> timing of phones in the same format as above. >> >> >> Best regards, >> Arif >> >> >> ------------------------------------------------------------------------------ >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community >> Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> Kaldi-developers mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers >> >> > > |
From: Arif K. <ife...@gm...> - 2014-06-26 09:18:14
|
Thanks Dan for your reply. I used the ali-to-phones module with --write-lengths options, which gives me the time stamps of each phone like this: *01pc0201* 1 87 ; 172 12 ; 222 4 ; 237 12 ; 92 8 ; ................ As you said its not in ctm format, Is there any script/module already for this to convert to a more human/usable format. Best regards, Arif On 6/24/14 7:08 PM, Daniel Povey wrote: > The program ali-to-phones should give you the information that you > need (when given the right options), but it won't be in a CTM-like > format. > Dan > > > > On Tue, Jun 24, 2014 at 1:06 PM, Arif Khan <ife...@gm... > <mailto:ife...@gm...>> wrote: > > Hi, > > In the "steps/get_train_ctm.sh", we can get the word alignment > which looks something like this: > > 018c021d 1 2.32 0.08 AN > 018c021d 1 2.40 0.46 APPARENT > 018c021d 1 2.86 0.59 SLOWDOWN > 018c021d 1 3.45 0.11 IN > 018c021d 1 3.56 0.58 ECONOMIC > 018c021d 1 4.14 0.30 GROWTH > > Is there any recipe to get the phone alignment. i.e Beginning and > End timing of phones in the same format as above. > > > Best regards, > Arif > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and > Eclipse > Turn processes into business applications with Bonita BPM > Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > <mailto:Kal...@li...> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > |
From: Daniel P. <dp...@gm...> - 2014-06-25 16:21:13
|
The only way that I could see a CMake build process being maintained is if we find a way to automatically create the CMake makefiles (whatever they are called) from the standard Makefiles. Otherwise we will have to maintain two separate build systems, which is too much hassle. If you are interested in contributing such scripts, and you can do it in a way that doesn't create too much visible 'clutter' in the current setup, that would be nice. Is there a reason you would prefer CMake? Dan On Wed, Jun 25, 2014 at 12:08 PM, Ricard Marxer <r.m...@sh...> wrote: > Hi there, > > I see there has been some discussion about creating Cmake scripts to build > Kaldi: > http://sourceforge.net/p/kaldi/mailman/message/31929858/ > > What's the status of this? > I'm also interested in an alternative way to build the library. > > Thanks > ricard > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > |
From: Ricard M. <r.m...@sh...> - 2014-06-25 16:08:25
|
Hi there, I see there has been some discussion about creating Cmake scripts to build Kaldi: http://sourceforge.net/p/kaldi/mailman/message/31929858/ What's the status of this? I'm also interested in an alternative way to build the library. Thanks ricard |
From: <jen...@a2...> - 2014-06-25 12:56:43
|
Kaldi - Build # 568 - Still Failing: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-06-25 12:36:36
|
Kaldi - Build # 567 - Still Failing: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-06-25 12:11:39
|
Kaldi - Build # 566 - Still Failing: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-06-25 08:38:53
|
Kaldi - Build # 565 - Still Failing: See the build log in attachment for the details. |
From: <jen...@a2...> - 2014-06-25 05:51:41
|
Kaldi - Build # 564 - Failure: See the build log in attachment for the details. |