Menu
▾
▴
kaldi-developers — Kaldi Developers
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: Tanel A. <tan...@ph...> - 2015-06-03 10:29:53
|
OK, I see. Try replacing the line (in the original Makefile): EXTRA_LDLIBS += -pthread -lgstbase-1.0 -lgstcontroller-1.0 -lgstreamer-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 with: EXTRA_LDLIBS += -pthread -lgstbase-1.0 -lgstcontroller-1.0 -lgmodule-2.0 -lgthread-2.0 -lrt EXTRA_LDLIBS += $(shell pkg-config --libs gstreamer-1.0) EXTRA_LDLIBS += $(shell pkg-config --libs glib-2.0) Does it help? Tanel On Wed, 2015-06-03 at 14:53 +0530, Niranjan Viladkar wrote: > Hello, > > > Thanks for the quick reply. I am using RHEL 6.2. > My glib installation is under my user area (/home/niranjan/* ... ). > > > Output of "pkg-config --cflags glib-2.0" => > -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/include/glib-2.0 > -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/lib/glib-2.0/include > > > Output of "pkg-config --cflags --libs glib-2.0" => > -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/include/glib-2.0 > -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/lib/glib-2.0/include > -L/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/lib -lglib-2.0 > > > I agree that "-lglib-2.0" gets included via EXTRA_LDLIBS. > > But as my glib installation is local, "-L" information is additional. > (I don't have root/sudo access) > > > Secondly, is the change in rule required? (addition of EXTRA_CXXFLAGS) > > 41 $(LIBFILE): $(OBJFILES) > 42 $(CXX) -shared -DPIC -o $(LIBFILE) -Wl,-soname=$(LIBFILE) > -Wl,--no-as-needed \ > 43 -L$(KALDILIBDIR) -Wl,-rpath=$(KALDILIBDIR) > $(EXTRA_LDLIBS) $(LDLIBS) $(LDFLAGS) $(EXTRA_CXXFLAGS) \ > 44 $(OBJFILES) > > Thanks, > > Niranjan. > > > On 3 June 2015 at 14:18, Tanel Alumäe <tan...@ph...> > wrote: > Hello, > > On my system (Debian testing, amd64), the output of > `pkg-config --cflags > glib-2.0` is: > -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > > The output of `pkg-config --cflags --libs glib-2.0` is: > -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -lglib-2.0 > > So, the only difference is the "-lglib-2.0" flag, which is > already > included in EXTRA_LDLIBS, which is included in the linker > flags on line > 43. > > What OS are you using? Can you give your output of the > commands > `pkg-config --cflags glib-2.0` and `pkg-config --cflags --libs > glib-2.0`? > > > Regards, > > Tanel > > > On Wed, 2015-06-03 at 13:17 +0530, Niranjan Viladkar wrote: > > Hello, > > > > > > I am new to kaldi. I am at revision 5112. > > > > > > I had to make following changes to src/gst-plugin/Makefile - > > > > in line 9 and 10, add "--libs" flag. > > > > for eg. > > > > 9 EXTRA_CXXFLAGS += $(shell pkg-config --cflags --libs > > gstreamer-1.0) > > 10 EXTRA_CXXFLAGS += $(shell pkg-config --cflags --libs > glib-2.0) > > > > > > and I had to include $(EXTRA_CXXFLAGS) in the rule > corresponding to > > $(LIBFILE) at line no. 41. > > > > For eg. > > > > 41 $(LIBFILE): $(OBJFILES) > > 42 $(CXX) -shared -DPIC -o $(LIBFILE) -Wl,-soname= > $(LIBFILE) > > -Wl,--no-as-needed \ > > 43 -L$(KALDILIBDIR) -Wl,-rpath=$(KALDILIBDIR) > > $(EXTRA_LDLIBS) $(LDLIBS) $(LDFLAGS) $(EXTRA_CXXFLAGS) \ > > 44 $(OBJFILES) > > > > > > > > Before these changes, "make" was failing as it could not > find gst > > specific plugins from $(EXTRA_LDLIBS). > > (I have gstreamer and glib installed in local area as I > don't have a > > root access on my system) > > > > > > Are these changes correct? > > If yes, they can be included in Makefile. > > If not, then what is correct way of building gstreamer > without > > modifications to the Makefile. > > > > > > Thanks in advance, > > > > Niranjan. > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > -- > Effort is important, but knowing where to make an effort in your life > makes all the difference. |
|
From: Niranjan V. <nvi...@gm...> - 2015-06-03 09:24:14
|
Hello, Thanks for the quick reply. I am using RHEL 6.2. My glib installation is under my user area (/home/niranjan/* ... ). Output of "pkg-config --cflags glib-2.0" => -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/include/glib-2.0 -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/lib/glib-2.0/include Output of "pkg-config --cflags --libs glib-2.0" => -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/include/glib-2.0 -I/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/lib/glib-2.0/include -L/home/niranjan/kaldi-svn/tools/glib/glib-2.45.2/lib -lglib-2.0 I agree that "-lglib-2.0" gets included via EXTRA_LDLIBS. But as my glib installation is local, "-L" information is additional. (I don't have root/sudo access) Secondly, is the change in rule required? (addition of EXTRA_CXXFLAGS) 41 $(LIBFILE): $(OBJFILES) 42 $(CXX) -shared -DPIC -o $(LIBFILE) -Wl,-soname=$(LIBFILE) -Wl,--no-as-needed \ 43 -L$(KALDILIBDIR) -Wl,-rpath=$(KALDILIBDIR) $(EXTRA_LDLIBS) $(LDLIBS) $(LDFLAGS) $(EXTRA_CXXFLAGS) \ 44 $(OBJFILES) Thanks, Niranjan. On 3 June 2015 at 14:18, Tanel Alumäe <tan...@ph...> wrote: > Hello, > > On my system (Debian testing, amd64), the output of `pkg-config --cflags > glib-2.0` is: > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > > The output of `pkg-config --cflags --libs glib-2.0` is: > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -lglib-2.0 > > So, the only difference is the "-lglib-2.0" flag, which is already > included in EXTRA_LDLIBS, which is included in the linker flags on line > 43. > > What OS are you using? Can you give your output of the commands > `pkg-config --cflags glib-2.0` and `pkg-config --cflags --libs > glib-2.0`? > > > Regards, > > Tanel > > > On Wed, 2015-06-03 at 13:17 +0530, Niranjan Viladkar wrote: > > Hello, > > > > > > I am new to kaldi. I am at revision 5112. > > > > > > I had to make following changes to src/gst-plugin/Makefile - > > > > in line 9 and 10, add "--libs" flag. > > > > for eg. > > > > 9 EXTRA_CXXFLAGS += $(shell pkg-config --cflags --libs > > gstreamer-1.0) > > 10 EXTRA_CXXFLAGS += $(shell pkg-config --cflags --libs glib-2.0) > > > > > > and I had to include $(EXTRA_CXXFLAGS) in the rule corresponding to > > $(LIBFILE) at line no. 41. > > > > For eg. > > > > 41 $(LIBFILE): $(OBJFILES) > > 42 $(CXX) -shared -DPIC -o $(LIBFILE) -Wl,-soname=$(LIBFILE) > > -Wl,--no-as-needed \ > > 43 -L$(KALDILIBDIR) -Wl,-rpath=$(KALDILIBDIR) > > $(EXTRA_LDLIBS) $(LDLIBS) $(LDFLAGS) $(EXTRA_CXXFLAGS) \ > > 44 $(OBJFILES) > > > > > > > > Before these changes, "make" was failing as it could not find gst > > specific plugins from $(EXTRA_LDLIBS). > > (I have gstreamer and glib installed in local area as I don't have a > > root access on my system) > > > > > > Are these changes correct? > > If yes, they can be included in Makefile. > > If not, then what is correct way of building gstreamer without > > modifications to the Makefile. > > > > > > Thanks in advance, > > > > Niranjan. > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > -- Effort is important, but knowing where to make an effort in your life makes all the difference. |
|
From: Tanel A. <tan...@ph...> - 2015-06-03 09:06:02
|
Hello, On my system (Debian testing, amd64), the output of `pkg-config --cflags glib-2.0` is: -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include The output of `pkg-config --cflags --libs glib-2.0` is: -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lglib-2.0 So, the only difference is the "-lglib-2.0" flag, which is already included in EXTRA_LDLIBS, which is included in the linker flags on line 43. What OS are you using? Can you give your output of the commands `pkg-config --cflags glib-2.0` and `pkg-config --cflags --libs glib-2.0`? Regards, Tanel On Wed, 2015-06-03 at 13:17 +0530, Niranjan Viladkar wrote: > Hello, > > > I am new to kaldi. I am at revision 5112. > > > I had to make following changes to src/gst-plugin/Makefile - > > in line 9 and 10, add "--libs" flag. > > for eg. > > 9 EXTRA_CXXFLAGS += $(shell pkg-config --cflags --libs > gstreamer-1.0) > 10 EXTRA_CXXFLAGS += $(shell pkg-config --cflags --libs glib-2.0) > > > and I had to include $(EXTRA_CXXFLAGS) in the rule corresponding to > $(LIBFILE) at line no. 41. > > For eg. > > 41 $(LIBFILE): $(OBJFILES) > 42 $(CXX) -shared -DPIC -o $(LIBFILE) -Wl,-soname=$(LIBFILE) > -Wl,--no-as-needed \ > 43 -L$(KALDILIBDIR) -Wl,-rpath=$(KALDILIBDIR) > $(EXTRA_LDLIBS) $(LDLIBS) $(LDFLAGS) $(EXTRA_CXXFLAGS) \ > 44 $(OBJFILES) > > > > Before these changes, "make" was failing as it could not find gst > specific plugins from $(EXTRA_LDLIBS). > (I have gstreamer and glib installed in local area as I don't have a > root access on my system) > > > Are these changes correct? > If yes, they can be included in Makefile. > If not, then what is correct way of building gstreamer without > modifications to the Makefile. > > > Thanks in advance, > > Niranjan. > > ------------------------------------------------------------------------------ > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Niranjan V. <nvi...@gm...> - 2015-06-03 07:48:20
|
Hello, I am new to kaldi. I am at revision 5112. I had to make following changes to src/gst-plugin/Makefile - in line 9 and 10, add "--libs" flag. for eg. 9 EXTRA_CXXFLAGS += $(shell pkg-config --cflags *--libs *gstreamer-1.0) 10 EXTRA_CXXFLAGS += $(shell pkg-config --cflags* --libs *glib-2.0) and I had to include $(EXTRA_CXXFLAGS) in the rule corresponding to $(LIBFILE) at line no. 41. For eg. 41 $(LIBFILE): $(OBJFILES) 42 $(CXX) -shared -DPIC -o $(LIBFILE) -Wl,-soname=$(LIBFILE) -Wl,--no-as-needed \ 43 -L$(KALDILIBDIR) -Wl,-rpath=$(KALDILIBDIR) $(EXTRA_LDLIBS) $(LDLIBS) $(LDFLAGS) *$(EXTRA_CXXFLAGS)* \ 44 $(OBJFILES) Before these changes, "make" was failing as it could not find gst specific plugins from $(EXTRA_LDLIBS). (I have gstreamer and glib installed in local area as I don't have a root access on my system) Are these changes correct? If yes, they can be included in Makefile. If not, then what is correct way of building gstreamer without modifications to the Makefile. Thanks in advance, Niranjan. |
|
From: Kirill K. <kir...@sm...> - 2015-05-27 04:35:52
|
Ah, so only a designated "main" result is computed on the test set, and that is the result of the speaker-adapted decode in this particular recipe, correct? -kkm > -----Original Message----- > From: Daniel Povey [mailto:dp...@gm...] > Sent: 2015-05-26 2028 > To: Kirill Katsnelson > Cc: kal...@li... > Subject: Re: [Kaldi-developers] librispeech nnet2 online test vs dev > sets > > Because we don't want to have a million different tests running for > different conditions. Some of the older scripts do, or did, test > without adaptation as a comparison. > Dan > > > On Tue, May 26, 2015 at 10:57 PM, Kirill Katsnelson > <kir...@sm...> wrote: > > Why nnet2 online decoding scripts do not use test sets for the online > speaker-unadapted decoding test? > > https://github.com/kaldi- > asr/kaldi/blob/master/egs/librispeech/s5/loca > > l/online/run_nnet2.sh#L123 > > > > The test sets are actually used only for speaker-adapted test (stage > 11 above). Why is that? > > > > -kkm > > --------------------------------------------------------------------- > - > > -------- _______________________________________________ > > Kaldi-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Daniel P. <dp...@gm...> - 2015-05-27 03:28:36
|
Because we don't want to have a million different tests running for different conditions. Some of the older scripts do, or did, test without adaptation as a comparison. Dan On Tue, May 26, 2015 at 10:57 PM, Kirill Katsnelson <kir...@sm...> wrote: > Why nnet2 online decoding scripts do not use test sets for the online speaker-unadapted decoding test? > https://github.com/kaldi-asr/kaldi/blob/master/egs/librispeech/s5/local/online/run_nnet2.sh#L123 > > The test sets are actually used only for speaker-adapted test (stage 11 above). Why is that? > > -kkm > ------------------------------------------------------------------------------ > _______________________________________________ > Kaldi-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Kirill K. <kir...@sm...> - 2015-05-27 02:57:27
|
Why nnet2 online decoding scripts do not use test sets for the online speaker-unadapted decoding test? https://github.com/kaldi-asr/kaldi/blob/master/egs/librispeech/s5/local/online/run_nnet2.sh#L123 The test sets are actually used only for speaker-adapted test (stage 11 above). Why is that? -kkm |
|
From: mohammad h. <moh...@ya...> - 2015-05-23 15:34:35
|
hello dearsI am running UBUNTU 12.04 64-bit on my computer.
I have been trying to install Kaldi and take all the steps but at last I have the following error:
...........................................................................................................................................................................
mohammad@MohammadReza:~/kaldi-trunk/src$ ./configure
Configuring ...
Checking OpenFST library in /home/mohammad/kaldi-trunk/tools/openfst ...
Checking OpenFst library was patched.
Backing up kaldi.mk to kaldi.mk.bak
Doing OS specific configurations ...
On Linux: Checking for linear algebra header files ...
Using ATLAS as the linear algebra library.
Atlas found in /usr/lib
... no {libatlas,libsatlas}.so in /usr/lib/atlas
... no {libatlas,libsatlas}.so in /usr/lib/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/lib/atlas-sse3
... no {libatlas,libsatlas}.so in /usr/lib64
... no {libatlas,libsatlas}.so in /usr/lib64/atlas
... no {libatlas,libsatlas}.so in /usr/lib64/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/lib64/atlas-sse3
... no {libatlas,libsatlas}.so in /usr/local/lib
... no {libatlas,libsatlas}.so in /usr/local/lib/atlas
... no {libatlas,libsatlas}.so in /usr/local/lib/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/local/lib/atlas-sse3
... no {libatlas,libsatlas}.so in /usr/local/lib64
... no {libatlas,libsatlas}.so in /usr/local/lib64/atlas
... no {libatlas,libsatlas}.so in /usr/local/lib64/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/local/lib64/atlas-sse3
... no {libatlas,libsatlas}.so in /home/mohammad/kaldi-trunk/src/../tools/ATLAS/build/install/lib/
... no {libatlas,libsatlas}.so in /home/mohammad/kaldi-trunk/tools/ATLAS/lib
Validating presence of ATLAS libs in /usr/lib
Using library /usr/lib/liblapack.so as ATLAS's CLAPACK library.
CUDA will not be used! If you have already installed cuda drivers and cuda toolkit, try using --cudatk-dir=... option. Note: this is only relevant for neural net experiments
Static=[false] Speex library not found: You can still build Kaldi without Speex.
Successfully configured for Linux [dynamic libraries] with ATLASLIBS =/usr/lib/liblapack.so /usr/lib/libcblas.so /usr/lib/libatlas.so /usr/lib/libf77blas.so
exp() time: 0.00359297
expf() time: 0.00739121
*** WARNING: expf() seems to be slower than exp() on your machine. This is a known bug in old versions of glibc. Please consider updating glibc. ***
*** Kaldi will be configured to use exp() instead of expf() in base/kaldi-math.h Exp() routine for single-precision floats.............................................................................................................................................................................
I have done the procedure in the instruction:
wget http://sourceforge.net/projects/math-atlas/files/Stable/3.8.3/atlas3.8.3.tar.gz
tar -xovzf atlas3.8.3.tar.gz ATLAS/include
I have still the same problem.
thanks if you help me with this problem.yours sincerelyMohammad Reza hasanabadi
|
|
From: mohammad h. <moh...@ya...> - 2015-05-23 15:28:40
|
hello dearsI am running UBUNTU 12.04 64-bit on my computer.
I have been trying to install Kaldi and take all the steps but at last I have the following error:
...........................................................................................................................................................................
mohammad@MohammadReza:~/kaldi-trunk/src$ ./configure
Configuring ...
Checking OpenFST library in /home/mohammad/kaldi-trunk/tools/openfst ...
Checking OpenFst library was patched.
Backing up kaldi.mk to kaldi.mk.bak
Doing OS specific configurations ...
On Linux: Checking for linear algebra header files ...
Using ATLAS as the linear algebra library.
Atlas found in /usr/lib
... no {libatlas,libsatlas}.so in /usr/lib/atlas
... no {libatlas,libsatlas}.so in /usr/lib/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/lib/atlas-sse3
... no {libatlas,libsatlas}.so in /usr/lib64
... no {libatlas,libsatlas}.so in /usr/lib64/atlas
... no {libatlas,libsatlas}.so in /usr/lib64/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/lib64/atlas-sse3
... no {libatlas,libsatlas}.so in /usr/local/lib
... no {libatlas,libsatlas}.so in /usr/local/lib/atlas
... no {libatlas,libsatlas}.so in /usr/local/lib/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/local/lib/atlas-sse3
... no {libatlas,libsatlas}.so in /usr/local/lib64
... no {libatlas,libsatlas}.so in /usr/local/lib64/atlas
... no {libatlas,libsatlas}.so in /usr/local/lib64/atlas-sse2
... no {libatlas,libsatlas}.so in /usr/local/lib64/atlas-sse3
... no {libatlas,libsatlas}.so in /home/mohammad/kaldi-trunk/src/../tools/ATLAS/build/install/lib/
... no {libatlas,libsatlas}.so in /home/mohammad/kaldi-trunk/tools/ATLAS/lib
Validating presence of ATLAS libs in /usr/lib
Using library /usr/lib/liblapack.so as ATLAS's CLAPACK library.
CUDA will not be used! If you have already installed cuda drivers and cuda toolkit, try using --cudatk-dir=... option. Note: this is only relevant for neural net experiments
Static=[false] Speex library not found: You can still build Kaldi without Speex.
Successfully configured for Linux [dynamic libraries] with ATLASLIBS =/usr/lib/liblapack.so /usr/lib/libcblas.so /usr/lib/libatlas.so /usr/lib/libf77blas.so
exp() time: 0.00359297
expf() time: 0.00739121
*** WARNING: expf() seems to be slower than exp() on your machine. This is a known bug in old versions of glibc. Please consider updating glibc. ***
*** Kaldi will be configured to use exp() instead of expf() in base/kaldi-math.h Exp() routine for single-precision floats.............................................................................................................................................................................
I have done the procedure in the instruction:
wget http://sourceforge.net/projects/math-atlas/files/Stable/3.8.3/atlas3.8.3.tar.gz
tar -xovzf atlas3.8.3.tar.gz ATLAS/include
I have still the same problem.
thanks if you help me with this problem.yours sincerelyMohammad Reza hasanabadi
|
|
From: Daniel P. <dp...@gm...> - 2015-05-19 21:29:40
|
Removing kaldi-developers via bcc.
Obviously it's very confusing. However, I notice in your patch to
kaldi-types.h, if using MSVC you are including basestd.h instead of
stdint.h, while OpenFst uses stdint.h. If we can ensure that the
types resolve to the same thing, things should work regardless of the
compiler bug. I think the easiest fix might be to just use stdint.h,
the same as OpenFst, when using MSVC- if it is available.
Dan
On Tue, May 19, 2015 at 5:20 PM, Kirill Katsnelson
<kir...@sm...> wrote:
> No dice. In fact, I have patched openfstwin (1.3.1 currently), and my fts/types.h looks like this, verbatim:
>
> #include <cstdlib> // for ssize_t
> #include <stdint.h> // *int*_t
>
> #include <fst/compat.h> // for DISALLOW_COPY_AND_ASSIGN
>
> #ifndef FST_LIB_TYPES_H__
> #define FST_LIB_TYPES_H__
>
> typedef int8_t int8;
> typedef int16_t int16;
> typedef int32_t int32;
> typedef int64_t int64;
>
> typedef uint8_t uint8;
> typedef uint16_t uint16;
> typedef uint32_t uint32;
> typedef uint64_t uint64;
>
> #endif // FST_LIB_TYPES_H__
>
> This is what the error happens with. The typedefs do not help.
>
> However, the code below, using Yenda's fix, compiles:
>
> #include "fst/fstlib.h"
> #include "fstext/fstext-lib.h"
> namespace fst {
> typedef ::int64 int64;
> }
> int main(int argc, char *argv[]) {
> using namespace kaldi;
> fst::VectorFst<fst::StdArc> phn2word;
> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true);
> }
>
> Now try to explain that...
>
> -kkm
>
>
>> -----Original Message-----
>> From: Daniel Povey [mailto:dp...@gm...]
>> Sent: 2015-05-19 1337
>> To: Kirill Katsnelson
>> Cc: kal...@li...
>> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>>
>> I see now that the error is not what I thought.
>> I just checked the OpenFst code and Mike Riley did fix the issue; the
>> types are now the same as the Kaldi ones, assuming you are not on
>> Windows: OpenFst code says:
>>
>> #include <stdint.h>
>> ...
>> typedef int16_t int16;
>> typedef int32_t int32;
>> typedef int64_t int64;
>> etc
>>
>>
>> The problem is that the Kaldi code doesn't use stdint.h if using MSVC,
>> because at the time we started, stdint.h did not exist on Windows.
>> But I think removing that #ifdef, and using stdint.h, which now seems
>> to exist on Windows, should probably resolve the issue. If ultimately
>> the typedef resolves to the same thing, I think the compiler doesn't
>> mind.
>> Dan
>>
>>
>>
>>
>> On Tue, May 19, 2015 at 4:30 PM, Kirill Katsnelson
>> <kir...@sm...> wrote:
>> > I am going back to reproduction the compile error in MSVC. I am using
>> bin/phones-to-prons as a simple example and have reduced the module to
>> the following exact lines:
>> >
>> > #include "fst/fstlib.h"
>> > #include "fstext/fstext-lib.h"
>> > int main(int argc, char *argv[]) {
>> > using namespace kaldi;
>> > fst::VectorFst<fst::StdArc> phn2word;
>> > fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL,
>> > false, true); // line 6 }
>> >
>> > The error message follows. Only MSVC reports it, the Intel compiler
>> has no problem here:
>> >
>> > C:\projects\kaldi\kaldi\extlibs\openfstwin-
>> 1.3.1\include\fst/script/print-impl.h(77): error C2872: 'int64' :
>> ambiguous symbol [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj]
>> > could be 'C:\projects\kaldi\kaldi\extlibs\openfstwin-
>> 1.3.1\include\fst/types.h(31) : int64_t int64'
>> > or 'C:\projects\kaldi\kaldi\src\base/kaldi-
>> types.h(48) : kaldi::int64'
>> > ..\../src/bin/phones-to-prons.cc(6) : see reference to
>> class
>> > template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled
>> >
>> > The line print-impl.h(77), containing the reportedly ambiguous
>> symbol, is essentially this:
>> >
>> > namespace fst {
>> > template <class A> class FstPrinter {
>> > void PrintId(int64 id, const SymbolTable *syms, const char *name)
>> const { // Line 77
>> > }
>> > };
>> > }
>> >
>> > This is indeed a compiler bug. The int64 does not even come from a
>> template parameter, and is unambiguously ::int64 in this scope, already
>> defined in an fst header.
>> >
>> > Now, you would think that the template is expanded in the lexical
>> scope of invocation, and thus preventing kaldi::int64 from being known
>> as just int64 at this point would be the fix. Yes it is a fix indeed,
>> but also is putting everything into the kaldi namespace. This compiles
>> without an error (then the linker complains about the missing _main,
>> but this is not a problem at this point):
>> >
>> > #include "fst/fstlib.h"
>> > #include "fstext/fstext-lib.h"
>> > namespace kaldi {
>> > int main(int argc, char *argv[]) {
>> > fst::VectorFst<fst::StdArc> phn2word;
>> > fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL,
>> > false, true); } }
>> >
>> > Why this works I do not know. Perhaps, kaldi::int64 is used in the
>> template expansion. But it is also a fix (or, better put, a
>> workaround).
>> >
>> > I agree that the fst library goes way too far when defining global
>> types int64 and friends (fst/types.h). But I do not know if it is
>> possible to change at this point. If it is redefined as "fst::int64",
>> kaldi is going to have trouble in modules having both "using namespace
>> kaldi" and "using namespace fst", I think.
>> >
>> > An amazingly ugly fix would be to define int64 as an alias to
>> kaldi::int64 etc., and then #define FST_LIB_TYPES_H__ before including
>> fst headers, thus preventing fst's definitions. I certainly would not
>> like to depend on an internal detail of the fst library though.
>> >
>> > -kkm
>> >
>> >> -----Original Message-----
>> >> From: Daniel Povey [mailto:dp...@gm...]
>> >> Sent: 2015-05-18 2011
>> >> To: Kirill Katsnelson
>> >> Cc: kal...@li...
>> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>> >>
>> >> Hm.
>> >> If the only issue is the int32and int64 definitions, I think a
>> >> cleaner fix would be to apply a patch to OpenFst to make it use the
>> >> same definitions that Kaldi uses (which is the "proper" way to do
>> it).
>> >> Dan
>> >>
>> >>
>> >> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson
>> >> <kir...@sm...> wrote:
>> >> > I am not exactly "moving" main() into namespace kaldi: there is
>> >> another, global main that calls kaldi::main(). The kaldi::main() can
>> >> be named anything, and also I do not think the standard prohibits
>> >> defining functions called main in other namespaces.
>> >> >
>> >> > There are at least two ways to deal with the bug we discussed a
>> few
>> >> days ago:
>> >> > 1. Move everything into namespace kaldi. In this case, the
>> >> > namespace-
>> >> local definitions (e. g. kaldi::int64) always win. Indeed, I am
>> >> adding a trivial main() that calls kaldi::main() in each program.
>> >> > 2. Declare all used types explicitly. This is what I did in the
>> >> couple files there, see the long banners of the using statements.
>> >> Simply "using namespace kaldi" does not cut it.
>> >> >
>> >> > Which of the two ways to select is a question I do not have much
>> >> opinion on.
>> >> >
>> >> > The error I am getting is about functions taking kaldi and
>> >> > openfst's
>> >> declared types int32 and int64 by pointer or by reference being
>> >> different and incompatible. I do not remember the exact message, but
>> >> I can easily roll back the change and see, if it would make more
>> sense.
>> >> >
>> >> > -kkm
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Daniel Povey [mailto:dp...@gm...]
>> >> >> Sent: 2015-05-18 1944
>> >> >> To: Kirill Katsnelson
>> >> >> Cc: kal...@li...
>> >> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>> >> >>
>> >> >> Thanks a lot for these.
>> >> >> Yenda will deal with the checking-in issues.
>> >> >> Generally speaking I like your patches, but I'll just reiterate
>> >> >> here some comments I made on github:
>> >> >> I'm not happy with the way you worked around the MSVC compiler
>> bug
>> >> by
>> >> >> moving main() into namespace kaldi. I believe this is not
>> >> >> allowed, e.g. see here
>> >> >> http://stackoverflow.com/questions/3956678/main-in-
>> >> >> namespace,
>> >> >> and even if it were allowed it seems very wrong to me; and I
>> doubt
>> >> it
>> >> >> would compile on all platforms. I'm OK to deal with MSVC's
>> >> >> brokenness by adding various #ifdefs, but actually breaking Kaldi
>> >> >> code is where I draw the line. I'm sure there must be less
>> >> >> heavyweight ways to deal with this problem? I don't know what
>> >> >> error message it was that you got, that you are trying to get rid
>> of?
>> >> >>
>> >> >>
>> >> >> Dan
>> >> >>
>> >> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson
>> >> >> <kir...@sm...> wrote:
>> >> >> > I have collected all my source changes into 4 separate commits
>> >> >> > in my
>> >> >> git fork. Please review the changes at the following links:
>> >> >> >
>> >> >> > The first change is trivial, but is necessary for the whole rig
>> >> >> > to
>> >> >> work properly. EOL conventions are hard to fix later and cause
>> the
>> >> >> most confusion in version control.
>> >> >> > https://github.com/kaldi-asr/kaldi/commit/bba053
>> >> >> >
>> >> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE
>> >> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d
>> >> >> >
>> >> >> > This is a change to fix the apparent MSVC bug with namespace
>> >> >> > resolution in template expansion
>> >> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7
>> >> >> >
>> >> >> > And the last deals with proper I/O binarization under Windows,
>> >> >> > and
>> >> >> Cygwin path conversions.
>> >> >> > The change depends on the 2nd from top above.
>> >> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3
>> >> >> >
>> >> >> > There are also changes to openfst files and headers, but I do
>> >> >> > not
>> >> >> know how to deal with them:
>> >> >> > - Check in the patches to be applied on top of existing
>> patches?
>> >> >> > - Provide pre-build binaries?
>> >> >> > - Check in complete sources as part of kaldi repo?
>> >> >> >
>> >> >> > And there are build scripts, coming soon.
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > -kkm
>> >> >> >
>> >> >> > ---------------------------------------------------------------
>> -
>> >> >> > --
>> >> -
>> >> >> > --
>> >> >> -
>> >> >> > -------- 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
>> >> >> > 50+ give you
>> >> >> > Actionable Insights Deep dive visibility with transaction
>> >> >> > tracing using APM Insight.
>> >> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> >> >> > _______________________________________________
>> >> >> > Kaldi-developers mailing list
>> >> >> > Kal...@li...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
|
|
From: Kirill K. <kir...@sm...> - 2015-05-19 21:20:21
|
No dice. In fact, I have patched openfstwin (1.3.1 currently), and my fts/types.h looks like this, verbatim:
#include <cstdlib> // for ssize_t
#include <stdint.h> // *int*_t
#include <fst/compat.h> // for DISALLOW_COPY_AND_ASSIGN
#ifndef FST_LIB_TYPES_H__
#define FST_LIB_TYPES_H__
typedef int8_t int8;
typedef int16_t int16;
typedef int32_t int32;
typedef int64_t int64;
typedef uint8_t uint8;
typedef uint16_t uint16;
typedef uint32_t uint32;
typedef uint64_t uint64;
#endif // FST_LIB_TYPES_H__
This is what the error happens with. The typedefs do not help.
However, the code below, using Yenda's fix, compiles:
#include "fst/fstlib.h"
#include "fstext/fstext-lib.h"
namespace fst {
typedef ::int64 int64;
}
int main(int argc, char *argv[]) {
using namespace kaldi;
fst::VectorFst<fst::StdArc> phn2word;
fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true);
}
Now try to explain that...
-kkm
> -----Original Message-----
> From: Daniel Povey [mailto:dp...@gm...]
> Sent: 2015-05-19 1337
> To: Kirill Katsnelson
> Cc: kal...@li...
> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>
> I see now that the error is not what I thought.
> I just checked the OpenFst code and Mike Riley did fix the issue; the
> types are now the same as the Kaldi ones, assuming you are not on
> Windows: OpenFst code says:
>
> #include <stdint.h>
> ...
> typedef int16_t int16;
> typedef int32_t int32;
> typedef int64_t int64;
> etc
>
>
> The problem is that the Kaldi code doesn't use stdint.h if using MSVC,
> because at the time we started, stdint.h did not exist on Windows.
> But I think removing that #ifdef, and using stdint.h, which now seems
> to exist on Windows, should probably resolve the issue. If ultimately
> the typedef resolves to the same thing, I think the compiler doesn't
> mind.
> Dan
>
>
>
>
> On Tue, May 19, 2015 at 4:30 PM, Kirill Katsnelson
> <kir...@sm...> wrote:
> > I am going back to reproduction the compile error in MSVC. I am using
> bin/phones-to-prons as a simple example and have reduced the module to
> the following exact lines:
> >
> > #include "fst/fstlib.h"
> > #include "fstext/fstext-lib.h"
> > int main(int argc, char *argv[]) {
> > using namespace kaldi;
> > fst::VectorFst<fst::StdArc> phn2word;
> > fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL,
> > false, true); // line 6 }
> >
> > The error message follows. Only MSVC reports it, the Intel compiler
> has no problem here:
> >
> > C:\projects\kaldi\kaldi\extlibs\openfstwin-
> 1.3.1\include\fst/script/print-impl.h(77): error C2872: 'int64' :
> ambiguous symbol [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj]
> > could be 'C:\projects\kaldi\kaldi\extlibs\openfstwin-
> 1.3.1\include\fst/types.h(31) : int64_t int64'
> > or 'C:\projects\kaldi\kaldi\src\base/kaldi-
> types.h(48) : kaldi::int64'
> > ..\../src/bin/phones-to-prons.cc(6) : see reference to
> class
> > template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled
> >
> > The line print-impl.h(77), containing the reportedly ambiguous
> symbol, is essentially this:
> >
> > namespace fst {
> > template <class A> class FstPrinter {
> > void PrintId(int64 id, const SymbolTable *syms, const char *name)
> const { // Line 77
> > }
> > };
> > }
> >
> > This is indeed a compiler bug. The int64 does not even come from a
> template parameter, and is unambiguously ::int64 in this scope, already
> defined in an fst header.
> >
> > Now, you would think that the template is expanded in the lexical
> scope of invocation, and thus preventing kaldi::int64 from being known
> as just int64 at this point would be the fix. Yes it is a fix indeed,
> but also is putting everything into the kaldi namespace. This compiles
> without an error (then the linker complains about the missing _main,
> but this is not a problem at this point):
> >
> > #include "fst/fstlib.h"
> > #include "fstext/fstext-lib.h"
> > namespace kaldi {
> > int main(int argc, char *argv[]) {
> > fst::VectorFst<fst::StdArc> phn2word;
> > fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL,
> > false, true); } }
> >
> > Why this works I do not know. Perhaps, kaldi::int64 is used in the
> template expansion. But it is also a fix (or, better put, a
> workaround).
> >
> > I agree that the fst library goes way too far when defining global
> types int64 and friends (fst/types.h). But I do not know if it is
> possible to change at this point. If it is redefined as "fst::int64",
> kaldi is going to have trouble in modules having both "using namespace
> kaldi" and "using namespace fst", I think.
> >
> > An amazingly ugly fix would be to define int64 as an alias to
> kaldi::int64 etc., and then #define FST_LIB_TYPES_H__ before including
> fst headers, thus preventing fst's definitions. I certainly would not
> like to depend on an internal detail of the fst library though.
> >
> > -kkm
> >
> >> -----Original Message-----
> >> From: Daniel Povey [mailto:dp...@gm...]
> >> Sent: 2015-05-18 2011
> >> To: Kirill Katsnelson
> >> Cc: kal...@li...
> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
> >>
> >> Hm.
> >> If the only issue is the int32and int64 definitions, I think a
> >> cleaner fix would be to apply a patch to OpenFst to make it use the
> >> same definitions that Kaldi uses (which is the "proper" way to do
> it).
> >> Dan
> >>
> >>
> >> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson
> >> <kir...@sm...> wrote:
> >> > I am not exactly "moving" main() into namespace kaldi: there is
> >> another, global main that calls kaldi::main(). The kaldi::main() can
> >> be named anything, and also I do not think the standard prohibits
> >> defining functions called main in other namespaces.
> >> >
> >> > There are at least two ways to deal with the bug we discussed a
> few
> >> days ago:
> >> > 1. Move everything into namespace kaldi. In this case, the
> >> > namespace-
> >> local definitions (e. g. kaldi::int64) always win. Indeed, I am
> >> adding a trivial main() that calls kaldi::main() in each program.
> >> > 2. Declare all used types explicitly. This is what I did in the
> >> couple files there, see the long banners of the using statements.
> >> Simply "using namespace kaldi" does not cut it.
> >> >
> >> > Which of the two ways to select is a question I do not have much
> >> opinion on.
> >> >
> >> > The error I am getting is about functions taking kaldi and
> >> > openfst's
> >> declared types int32 and int64 by pointer or by reference being
> >> different and incompatible. I do not remember the exact message, but
> >> I can easily roll back the change and see, if it would make more
> sense.
> >> >
> >> > -kkm
> >> >
> >> >> -----Original Message-----
> >> >> From: Daniel Povey [mailto:dp...@gm...]
> >> >> Sent: 2015-05-18 1944
> >> >> To: Kirill Katsnelson
> >> >> Cc: kal...@li...
> >> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
> >> >>
> >> >> Thanks a lot for these.
> >> >> Yenda will deal with the checking-in issues.
> >> >> Generally speaking I like your patches, but I'll just reiterate
> >> >> here some comments I made on github:
> >> >> I'm not happy with the way you worked around the MSVC compiler
> bug
> >> by
> >> >> moving main() into namespace kaldi. I believe this is not
> >> >> allowed, e.g. see here
> >> >> http://stackoverflow.com/questions/3956678/main-in-
> >> >> namespace,
> >> >> and even if it were allowed it seems very wrong to me; and I
> doubt
> >> it
> >> >> would compile on all platforms. I'm OK to deal with MSVC's
> >> >> brokenness by adding various #ifdefs, but actually breaking Kaldi
> >> >> code is where I draw the line. I'm sure there must be less
> >> >> heavyweight ways to deal with this problem? I don't know what
> >> >> error message it was that you got, that you are trying to get rid
> of?
> >> >>
> >> >>
> >> >> Dan
> >> >>
> >> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson
> >> >> <kir...@sm...> wrote:
> >> >> > I have collected all my source changes into 4 separate commits
> >> >> > in my
> >> >> git fork. Please review the changes at the following links:
> >> >> >
> >> >> > The first change is trivial, but is necessary for the whole rig
> >> >> > to
> >> >> work properly. EOL conventions are hard to fix later and cause
> the
> >> >> most confusion in version control.
> >> >> > https://github.com/kaldi-asr/kaldi/commit/bba053
> >> >> >
> >> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE
> >> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d
> >> >> >
> >> >> > This is a change to fix the apparent MSVC bug with namespace
> >> >> > resolution in template expansion
> >> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7
> >> >> >
> >> >> > And the last deals with proper I/O binarization under Windows,
> >> >> > and
> >> >> Cygwin path conversions.
> >> >> > The change depends on the 2nd from top above.
> >> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3
> >> >> >
> >> >> > There are also changes to openfst files and headers, but I do
> >> >> > not
> >> >> know how to deal with them:
> >> >> > - Check in the patches to be applied on top of existing
> patches?
> >> >> > - Provide pre-build binaries?
> >> >> > - Check in complete sources as part of kaldi repo?
> >> >> >
> >> >> > And there are build scripts, coming soon.
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > -kkm
> >> >> >
> >> >> > ---------------------------------------------------------------
> -
> >> >> > --
> >> -
> >> >> > --
> >> >> -
> >> >> > -------- 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
> >> >> > 50+ give you
> >> >> > Actionable Insights Deep dive visibility with transaction
> >> >> > tracing using APM Insight.
> >> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> >> > _______________________________________________
> >> >> > Kaldi-developers mailing list
> >> >> > Kal...@li...
> >> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
|
|
From: Jan T. <jt...@gm...> - 2015-05-19 21:07:13
|
Ok, I will look into it. It's getting late here, so I will get back to it tomorrow. Y. On May 19, 2015 10:43 PM, "Daniel Povey" <dp...@gm...> wrote: > BTW, according to this > > http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio > MSVC 2010 and later supports the almost the entire C99 standard > library including stdint.h. (only eleven years late!). > So I think we're safe to remove that #ifdef (Yenda, I'll leave it to > you). I don't think we need to support older-than-2010 MSVC versions: > that's already 5 years ago. > Dan > > > On Tue, May 19, 2015 at 4:37 PM, Daniel Povey <dp...@gm...> wrote: > > I see now that the error is not what I thought. > > I just checked the OpenFst code and Mike Riley did fix the issue; the > > types are now the same as the Kaldi ones, assuming you are not on > > Windows: OpenFst code says: > > > > #include <stdint.h> > > ... > > typedef int16_t int16; > > typedef int32_t int32; > > typedef int64_t int64; > > etc > > > > > > The problem is that the Kaldi code doesn't use stdint.h if using MSVC, > > because at the time we started, stdint.h did not exist on Windows. > > But I think removing that #ifdef, and using stdint.h, which now seems > > to exist on Windows, should probably resolve the issue. If ultimately > > the typedef resolves to the same thing, I think the compiler doesn't > > mind. > > Dan > > > > > > > > > > On Tue, May 19, 2015 at 4:30 PM, Kirill Katsnelson > > <kir...@sm...> wrote: > >> I am going back to reproduction the compile error in MSVC. I am using > bin/phones-to-prons as a simple example and have reduced the module to the > following exact lines: > >> > >> #include "fst/fstlib.h" > >> #include "fstext/fstext-lib.h" > >> int main(int argc, char *argv[]) { > >> using namespace kaldi; > >> fst::VectorFst<fst::StdArc> phn2word; > >> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, > false, true); // line 6 > >> } > >> > >> The error message follows. Only MSVC reports it, the Intel compiler has > no problem here: > >> > >> > C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/script/print-impl.h(77): > error C2872: 'int64' : ambiguous symbol > [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj] > >> could be > 'C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/types.h(31) : > int64_t int64' > >> or 'C:\projects\kaldi\kaldi\src\base/kaldi-types.h(48) > : kaldi::int64' > >> ..\../src/bin/phones-to-prons.cc(6) : see reference to class > template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled > >> > >> The line print-impl.h(77), containing the reportedly ambiguous symbol, > is essentially this: > >> > >> namespace fst { > >> template <class A> class FstPrinter { > >> void PrintId(int64 id, const SymbolTable *syms, const char *name) > const { // Line 77 > >> } > >> }; > >> } > >> > >> This is indeed a compiler bug. The int64 does not even come from a > template parameter, and is unambiguously ::int64 in this scope, already > defined in an fst header. > >> > >> Now, you would think that the template is expanded in the lexical scope > of invocation, and thus preventing kaldi::int64 from being known as just > int64 at this point would be the fix. Yes it is a fix indeed, but also is > putting everything into the kaldi namespace. This compiles without an error > (then the linker complains about the missing _main, but this is not a > problem at this point): > >> > >> #include "fst/fstlib.h" > >> #include "fstext/fstext-lib.h" > >> namespace kaldi { > >> int main(int argc, char *argv[]) { > >> fst::VectorFst<fst::StdArc> phn2word; > >> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, > false, true); > >> } > >> } > >> > >> Why this works I do not know. Perhaps, kaldi::int64 is used in the > template expansion. But it is also a fix (or, better put, a workaround). > >> > >> I agree that the fst library goes way too far when defining global > types int64 and friends (fst/types.h). But I do not know if it is possible > to change at this point. If it is redefined as "fst::int64", kaldi is going > to have trouble in modules having both "using namespace kaldi" and "using > namespace fst", I think. > >> > >> An amazingly ugly fix would be to define int64 as an alias to > kaldi::int64 etc., and then #define FST_LIB_TYPES_H__ before including fst > headers, thus preventing fst's definitions. I certainly would not like to > depend on an internal detail of the fst library though. > >> > >> -kkm > >> > >>> -----Original Message----- > >>> From: Daniel Povey [mailto:dp...@gm...] > >>> Sent: 2015-05-18 2011 > >>> To: Kirill Katsnelson > >>> Cc: kal...@li... > >>> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) > >>> > >>> Hm. > >>> If the only issue is the int32and int64 definitions, I think a cleaner > >>> fix would be to apply a patch to OpenFst to make it use the same > >>> definitions that Kaldi uses (which is the "proper" way to do it). > >>> Dan > >>> > >>> > >>> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson > >>> <kir...@sm...> wrote: > >>> > I am not exactly "moving" main() into namespace kaldi: there is > >>> another, global main that calls kaldi::main(). The kaldi::main() can be > >>> named anything, and also I do not think the standard prohibits defining > >>> functions called main in other namespaces. > >>> > > >>> > There are at least two ways to deal with the bug we discussed a few > >>> days ago: > >>> > 1. Move everything into namespace kaldi. In this case, the namespace- > >>> local definitions (e. g. kaldi::int64) always win. Indeed, I am adding > >>> a trivial main() that calls kaldi::main() in each program. > >>> > 2. Declare all used types explicitly. This is what I did in the > >>> couple files there, see the long banners of the using statements. > >>> Simply "using namespace kaldi" does not cut it. > >>> > > >>> > Which of the two ways to select is a question I do not have much > >>> opinion on. > >>> > > >>> > The error I am getting is about functions taking kaldi and openfst's > >>> declared types int32 and int64 by pointer or by reference being > >>> different and incompatible. I do not remember the exact message, but I > >>> can easily roll back the change and see, if it would make more sense. > >>> > > >>> > -kkm > >>> > > >>> >> -----Original Message----- > >>> >> From: Daniel Povey [mailto:dp...@gm...] > >>> >> Sent: 2015-05-18 1944 > >>> >> To: Kirill Katsnelson > >>> >> Cc: kal...@li... > >>> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) > >>> >> > >>> >> Thanks a lot for these. > >>> >> Yenda will deal with the checking-in issues. > >>> >> Generally speaking I like your patches, but I'll just reiterate here > >>> >> some comments I made on github: > >>> >> I'm not happy with the way you worked around the MSVC compiler bug > >>> by > >>> >> moving main() into namespace kaldi. I believe this is not allowed, > >>> >> e.g. see here http://stackoverflow.com/questions/3956678/main-in- > >>> >> namespace, > >>> >> and even if it were allowed it seems very wrong to me; and I doubt > >>> it > >>> >> would compile on all platforms. I'm OK to deal with MSVC's > >>> >> brokenness by adding various #ifdefs, but actually breaking Kaldi > >>> >> code is where I draw the line. I'm sure there must be less > >>> >> heavyweight ways to deal with this problem? I don't know what error > >>> >> message it was that you got, that you are trying to get rid of? > >>> >> > >>> >> > >>> >> Dan > >>> >> > >>> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson > >>> >> <kir...@sm...> wrote: > >>> >> > I have collected all my source changes into 4 separate commits in > >>> >> > my > >>> >> git fork. Please review the changes at the following links: > >>> >> > > >>> >> > The first change is trivial, but is necessary for the whole rig to > >>> >> work properly. EOL conventions are hard to fix later and cause the > >>> >> most confusion in version control. > >>> >> > https://github.com/kaldi-asr/kaldi/commit/bba053 > >>> >> > > >>> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE > >>> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d > >>> >> > > >>> >> > This is a change to fix the apparent MSVC bug with namespace > >>> >> > resolution in template expansion > >>> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 > >>> >> > > >>> >> > And the last deals with proper I/O binarization under Windows, and > >>> >> Cygwin path conversions. > >>> >> > The change depends on the 2nd from top above. > >>> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 > >>> >> > > >>> >> > There are also changes to openfst files and headers, but I do not > >>> >> know how to deal with them: > >>> >> > - Check in the patches to be applied on top of existing patches? > >>> >> > - Provide pre-build binaries? > >>> >> > - Check in complete sources as part of kaldi repo? > >>> >> > > >>> >> > And there are build scripts, coming soon. > >>> >> > > >>> >> > Thanks, > >>> >> > > >>> >> > -kkm > >>> >> > > >>> >> > ------------------------------------------------------------------ > >>> - > >>> >> > -- > >>> >> - > >>> >> > -------- 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 > >>> >> > 50+ you > >>> >> > Actionable Insights Deep dive visibility with transaction tracing > >>> >> > using APM Insight. > >>> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > >>> >> > _______________________________________________ > >>> >> > Kaldi-developers mailing list > >>> >> > Kal...@li... > >>> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > > > ------------------------------------------------------------------------------ > 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-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > |
|
From: Jan T. <jt...@gm...> - 2015-05-19 20:53:23
|
Kirill, did you tried to compile against the patched openfstwin? I think I
addressed the type lookup issues.
Y.
On May 19, 2015 10:31 PM, "Kirill Katsnelson" <
kir...@sm...> wrote:
> I am going back to reproduction the compile error in MSVC. I am using
> bin/phones-to-prons as a simple example and have reduced the module to the
> following exact lines:
>
> #include "fst/fstlib.h"
> #include "fstext/fstext-lib.h"
> int main(int argc, char *argv[]) {
> using namespace kaldi;
> fst::VectorFst<fst::StdArc> phn2word;
> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL,
> false, true); // line 6
> }
>
> The error message follows. Only MSVC reports it, the Intel compiler has no
> problem here:
>
> C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/script/print-impl.h(77):
> error C2872: 'int64' : ambiguous symbol
> [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj]
> could be
> 'C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/types.h(31) :
> int64_t int64'
> or 'C:\projects\kaldi\kaldi\src\base/kaldi-types.h(48) :
> kaldi::int64'
> ..\../src/bin/phones-to-prons.cc(6) : see reference to class
> template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled
>
> The line print-impl.h(77), containing the reportedly ambiguous symbol, is
> essentially this:
>
> namespace fst {
> template <class A> class FstPrinter {
> void PrintId(int64 id, const SymbolTable *syms, const char *name) const
> { // Line 77
> }
> };
> }
>
> This is indeed a compiler bug. The int64 does not even come from a
> template parameter, and is unambiguously ::int64 in this scope, already
> defined in an fst header.
>
> Now, you would think that the template is expanded in the lexical scope of
> invocation, and thus preventing kaldi::int64 from being known as just int64
> at this point would be the fix. Yes it is a fix indeed, but also is putting
> everything into the kaldi namespace. This compiles without an error (then
> the linker complains about the missing _main, but this is not a problem at
> this point):
>
> #include "fst/fstlib.h"
> #include "fstext/fstext-lib.h"
> namespace kaldi {
> int main(int argc, char *argv[]) {
> fst::VectorFst<fst::StdArc> phn2word;
> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL,
> false, true);
> }
> }
>
> Why this works I do not know. Perhaps, kaldi::int64 is used in the
> template expansion. But it is also a fix (or, better put, a workaround).
>
> I agree that the fst library goes way too far when defining global types
> int64 and friends (fst/types.h). But I do not know if it is possible to
> change at this point. If it is redefined as "fst::int64", kaldi is going to
> have trouble in modules having both "using namespace kaldi" and "using
> namespace fst", I think.
>
> An amazingly ugly fix would be to define int64 as an alias to kaldi::int64
> etc., and then #define FST_LIB_TYPES_H__ before including fst headers, thus
> preventing fst's definitions. I certainly would not like to depend on an
> internal detail of the fst library though.
>
> -kkm
>
> > -----Original Message-----
> > From: Daniel Povey [mailto:dp...@gm...]
> > Sent: 2015-05-18 2011
> > To: Kirill Katsnelson
> > Cc: kal...@li...
> > Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
> >
> > Hm.
> > If the only issue is the int32and int64 definitions, I think a cleaner
> > fix would be to apply a patch to OpenFst to make it use the same
> > definitions that Kaldi uses (which is the "proper" way to do it).
> > Dan
> >
> >
> > On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson
> > <kir...@sm...> wrote:
> > > I am not exactly "moving" main() into namespace kaldi: there is
> > another, global main that calls kaldi::main(). The kaldi::main() can be
> > named anything, and also I do not think the standard prohibits defining
> > functions called main in other namespaces.
> > >
> > > There are at least two ways to deal with the bug we discussed a few
> > days ago:
> > > 1. Move everything into namespace kaldi. In this case, the namespace-
> > local definitions (e. g. kaldi::int64) always win. Indeed, I am adding
> > a trivial main() that calls kaldi::main() in each program.
> > > 2. Declare all used types explicitly. This is what I did in the
> > couple files there, see the long banners of the using statements.
> > Simply "using namespace kaldi" does not cut it.
> > >
> > > Which of the two ways to select is a question I do not have much
> > opinion on.
> > >
> > > The error I am getting is about functions taking kaldi and openfst's
> > declared types int32 and int64 by pointer or by reference being
> > different and incompatible. I do not remember the exact message, but I
> > can easily roll back the change and see, if it would make more sense.
> > >
> > > -kkm
> > >
> > >> -----Original Message-----
> > >> From: Daniel Povey [mailto:dp...@gm...]
> > >> Sent: 2015-05-18 1944
> > >> To: Kirill Katsnelson
> > >> Cc: kal...@li...
> > >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
> > >>
> > >> Thanks a lot for these.
> > >> Yenda will deal with the checking-in issues.
> > >> Generally speaking I like your patches, but I'll just reiterate here
> > >> some comments I made on github:
> > >> I'm not happy with the way you worked around the MSVC compiler bug
> > by
> > >> moving main() into namespace kaldi. I believe this is not allowed,
> > >> e.g. see here http://stackoverflow.com/questions/3956678/main-in-
> > >> namespace,
> > >> and even if it were allowed it seems very wrong to me; and I doubt
> > it
> > >> would compile on all platforms. I'm OK to deal with MSVC's
> > >> brokenness by adding various #ifdefs, but actually breaking Kaldi
> > >> code is where I draw the line. I'm sure there must be less
> > >> heavyweight ways to deal with this problem? I don't know what error
> > >> message it was that you got, that you are trying to get rid of?
> > >>
> > >>
> > >> Dan
> > >>
> > >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson
> > >> <kir...@sm...> wrote:
> > >> > I have collected all my source changes into 4 separate commits in
> > >> > my
> > >> git fork. Please review the changes at the following links:
> > >> >
> > >> > The first change is trivial, but is necessary for the whole rig to
> > >> work properly. EOL conventions are hard to fix later and cause the
> > >> most confusion in version control.
> > >> > https://github.com/kaldi-asr/kaldi/commit/bba053
> > >> >
> > >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE
> > >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d
> > >> >
> > >> > This is a change to fix the apparent MSVC bug with namespace
> > >> > resolution in template expansion
> > >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7
> > >> >
> > >> > And the last deals with proper I/O binarization under Windows, and
> > >> Cygwin path conversions.
> > >> > The change depends on the 2nd from top above.
> > >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3
> > >> >
> > >> > There are also changes to openfst files and headers, but I do not
> > >> know how to deal with them:
> > >> > - Check in the patches to be applied on top of existing patches?
> > >> > - Provide pre-build binaries?
> > >> > - Check in complete sources as part of kaldi repo?
> > >> >
> > >> > And there are build scripts, coming soon.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > -kkm
> > >> >
> > >> > ------------------------------------------------------------------
> > -
> > >> > --
> > >> -
> > >> > -------- 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
> > >> > 50+ you
> > >> > Actionable Insights Deep dive visibility with transaction tracing
> > >> > using APM Insight.
> > >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >> > _______________________________________________
> > >> > Kaldi-developers mailing list
> > >> > Kal...@li...
> > >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
|
|
From: Daniel P. <dp...@gm...> - 2015-05-19 20:42:50
|
BTW, according to this http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio MSVC 2010 and later supports the almost the entire C99 standard library including stdint.h. (only eleven years late!). So I think we're safe to remove that #ifdef (Yenda, I'll leave it to you). I don't think we need to support older-than-2010 MSVC versions: that's already 5 years ago. Dan On Tue, May 19, 2015 at 4:37 PM, Daniel Povey <dp...@gm...> wrote: > I see now that the error is not what I thought. > I just checked the OpenFst code and Mike Riley did fix the issue; the > types are now the same as the Kaldi ones, assuming you are not on > Windows: OpenFst code says: > > #include <stdint.h> > ... > typedef int16_t int16; > typedef int32_t int32; > typedef int64_t int64; > etc > > > The problem is that the Kaldi code doesn't use stdint.h if using MSVC, > because at the time we started, stdint.h did not exist on Windows. > But I think removing that #ifdef, and using stdint.h, which now seems > to exist on Windows, should probably resolve the issue. If ultimately > the typedef resolves to the same thing, I think the compiler doesn't > mind. > Dan > > > > > On Tue, May 19, 2015 at 4:30 PM, Kirill Katsnelson > <kir...@sm...> wrote: >> I am going back to reproduction the compile error in MSVC. I am using bin/phones-to-prons as a simple example and have reduced the module to the following exact lines: >> >> #include "fst/fstlib.h" >> #include "fstext/fstext-lib.h" >> int main(int argc, char *argv[]) { >> using namespace kaldi; >> fst::VectorFst<fst::StdArc> phn2word; >> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true); // line 6 >> } >> >> The error message follows. Only MSVC reports it, the Intel compiler has no problem here: >> >> C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/script/print-impl.h(77): error C2872: 'int64' : ambiguous symbol [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj] >> could be 'C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/types.h(31) : int64_t int64' >> or 'C:\projects\kaldi\kaldi\src\base/kaldi-types.h(48) : kaldi::int64' >> ..\../src/bin/phones-to-prons.cc(6) : see reference to class template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled >> >> The line print-impl.h(77), containing the reportedly ambiguous symbol, is essentially this: >> >> namespace fst { >> template <class A> class FstPrinter { >> void PrintId(int64 id, const SymbolTable *syms, const char *name) const { // Line 77 >> } >> }; >> } >> >> This is indeed a compiler bug. The int64 does not even come from a template parameter, and is unambiguously ::int64 in this scope, already defined in an fst header. >> >> Now, you would think that the template is expanded in the lexical scope of invocation, and thus preventing kaldi::int64 from being known as just int64 at this point would be the fix. Yes it is a fix indeed, but also is putting everything into the kaldi namespace. This compiles without an error (then the linker complains about the missing _main, but this is not a problem at this point): >> >> #include "fst/fstlib.h" >> #include "fstext/fstext-lib.h" >> namespace kaldi { >> int main(int argc, char *argv[]) { >> fst::VectorFst<fst::StdArc> phn2word; >> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true); >> } >> } >> >> Why this works I do not know. Perhaps, kaldi::int64 is used in the template expansion. But it is also a fix (or, better put, a workaround). >> >> I agree that the fst library goes way too far when defining global types int64 and friends (fst/types.h). But I do not know if it is possible to change at this point. If it is redefined as "fst::int64", kaldi is going to have trouble in modules having both "using namespace kaldi" and "using namespace fst", I think. >> >> An amazingly ugly fix would be to define int64 as an alias to kaldi::int64 etc., and then #define FST_LIB_TYPES_H__ before including fst headers, thus preventing fst's definitions. I certainly would not like to depend on an internal detail of the fst library though. >> >> -kkm >> >>> -----Original Message----- >>> From: Daniel Povey [mailto:dp...@gm...] >>> Sent: 2015-05-18 2011 >>> To: Kirill Katsnelson >>> Cc: kal...@li... >>> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >>> >>> Hm. >>> If the only issue is the int32and int64 definitions, I think a cleaner >>> fix would be to apply a patch to OpenFst to make it use the same >>> definitions that Kaldi uses (which is the "proper" way to do it). >>> Dan >>> >>> >>> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson >>> <kir...@sm...> wrote: >>> > I am not exactly "moving" main() into namespace kaldi: there is >>> another, global main that calls kaldi::main(). The kaldi::main() can be >>> named anything, and also I do not think the standard prohibits defining >>> functions called main in other namespaces. >>> > >>> > There are at least two ways to deal with the bug we discussed a few >>> days ago: >>> > 1. Move everything into namespace kaldi. In this case, the namespace- >>> local definitions (e. g. kaldi::int64) always win. Indeed, I am adding >>> a trivial main() that calls kaldi::main() in each program. >>> > 2. Declare all used types explicitly. This is what I did in the >>> couple files there, see the long banners of the using statements. >>> Simply "using namespace kaldi" does not cut it. >>> > >>> > Which of the two ways to select is a question I do not have much >>> opinion on. >>> > >>> > The error I am getting is about functions taking kaldi and openfst's >>> declared types int32 and int64 by pointer or by reference being >>> different and incompatible. I do not remember the exact message, but I >>> can easily roll back the change and see, if it would make more sense. >>> > >>> > -kkm >>> > >>> >> -----Original Message----- >>> >> From: Daniel Povey [mailto:dp...@gm...] >>> >> Sent: 2015-05-18 1944 >>> >> To: Kirill Katsnelson >>> >> Cc: kal...@li... >>> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >>> >> >>> >> Thanks a lot for these. >>> >> Yenda will deal with the checking-in issues. >>> >> Generally speaking I like your patches, but I'll just reiterate here >>> >> some comments I made on github: >>> >> I'm not happy with the way you worked around the MSVC compiler bug >>> by >>> >> moving main() into namespace kaldi. I believe this is not allowed, >>> >> e.g. see here http://stackoverflow.com/questions/3956678/main-in- >>> >> namespace, >>> >> and even if it were allowed it seems very wrong to me; and I doubt >>> it >>> >> would compile on all platforms. I'm OK to deal with MSVC's >>> >> brokenness by adding various #ifdefs, but actually breaking Kaldi >>> >> code is where I draw the line. I'm sure there must be less >>> >> heavyweight ways to deal with this problem? I don't know what error >>> >> message it was that you got, that you are trying to get rid of? >>> >> >>> >> >>> >> Dan >>> >> >>> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson >>> >> <kir...@sm...> wrote: >>> >> > I have collected all my source changes into 4 separate commits in >>> >> > my >>> >> git fork. Please review the changes at the following links: >>> >> > >>> >> > The first change is trivial, but is necessary for the whole rig to >>> >> work properly. EOL conventions are hard to fix later and cause the >>> >> most confusion in version control. >>> >> > https://github.com/kaldi-asr/kaldi/commit/bba053 >>> >> > >>> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE >>> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d >>> >> > >>> >> > This is a change to fix the apparent MSVC bug with namespace >>> >> > resolution in template expansion >>> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 >>> >> > >>> >> > And the last deals with proper I/O binarization under Windows, and >>> >> Cygwin path conversions. >>> >> > The change depends on the 2nd from top above. >>> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 >>> >> > >>> >> > There are also changes to openfst files and headers, but I do not >>> >> know how to deal with them: >>> >> > - Check in the patches to be applied on top of existing patches? >>> >> > - Provide pre-build binaries? >>> >> > - Check in complete sources as part of kaldi repo? >>> >> > >>> >> > And there are build scripts, coming soon. >>> >> > >>> >> > Thanks, >>> >> > >>> >> > -kkm >>> >> > >>> >> > ------------------------------------------------------------------ >>> - >>> >> > -- >>> >> - >>> >> > -------- 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 >>> >> > 50+ you >>> >> > Actionable Insights Deep dive visibility with transaction tracing >>> >> > using APM Insight. >>> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> >> > _______________________________________________ >>> >> > Kaldi-developers mailing list >>> >> > Kal...@li... >>> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Daniel P. <dp...@gm...> - 2015-05-19 20:37:14
|
I see now that the error is not what I thought.
I just checked the OpenFst code and Mike Riley did fix the issue; the
types are now the same as the Kaldi ones, assuming you are not on
Windows: OpenFst code says:
#include <stdint.h>
...
typedef int16_t int16;
typedef int32_t int32;
typedef int64_t int64;
etc
The problem is that the Kaldi code doesn't use stdint.h if using MSVC,
because at the time we started, stdint.h did not exist on Windows.
But I think removing that #ifdef, and using stdint.h, which now seems
to exist on Windows, should probably resolve the issue. If ultimately
the typedef resolves to the same thing, I think the compiler doesn't
mind.
Dan
On Tue, May 19, 2015 at 4:30 PM, Kirill Katsnelson
<kir...@sm...> wrote:
> I am going back to reproduction the compile error in MSVC. I am using bin/phones-to-prons as a simple example and have reduced the module to the following exact lines:
>
> #include "fst/fstlib.h"
> #include "fstext/fstext-lib.h"
> int main(int argc, char *argv[]) {
> using namespace kaldi;
> fst::VectorFst<fst::StdArc> phn2word;
> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true); // line 6
> }
>
> The error message follows. Only MSVC reports it, the Intel compiler has no problem here:
>
> C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/script/print-impl.h(77): error C2872: 'int64' : ambiguous symbol [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj]
> could be 'C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/types.h(31) : int64_t int64'
> or 'C:\projects\kaldi\kaldi\src\base/kaldi-types.h(48) : kaldi::int64'
> ..\../src/bin/phones-to-prons.cc(6) : see reference to class template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled
>
> The line print-impl.h(77), containing the reportedly ambiguous symbol, is essentially this:
>
> namespace fst {
> template <class A> class FstPrinter {
> void PrintId(int64 id, const SymbolTable *syms, const char *name) const { // Line 77
> }
> };
> }
>
> This is indeed a compiler bug. The int64 does not even come from a template parameter, and is unambiguously ::int64 in this scope, already defined in an fst header.
>
> Now, you would think that the template is expanded in the lexical scope of invocation, and thus preventing kaldi::int64 from being known as just int64 at this point would be the fix. Yes it is a fix indeed, but also is putting everything into the kaldi namespace. This compiles without an error (then the linker complains about the missing _main, but this is not a problem at this point):
>
> #include "fst/fstlib.h"
> #include "fstext/fstext-lib.h"
> namespace kaldi {
> int main(int argc, char *argv[]) {
> fst::VectorFst<fst::StdArc> phn2word;
> fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true);
> }
> }
>
> Why this works I do not know. Perhaps, kaldi::int64 is used in the template expansion. But it is also a fix (or, better put, a workaround).
>
> I agree that the fst library goes way too far when defining global types int64 and friends (fst/types.h). But I do not know if it is possible to change at this point. If it is redefined as "fst::int64", kaldi is going to have trouble in modules having both "using namespace kaldi" and "using namespace fst", I think.
>
> An amazingly ugly fix would be to define int64 as an alias to kaldi::int64 etc., and then #define FST_LIB_TYPES_H__ before including fst headers, thus preventing fst's definitions. I certainly would not like to depend on an internal detail of the fst library though.
>
> -kkm
>
>> -----Original Message-----
>> From: Daniel Povey [mailto:dp...@gm...]
>> Sent: 2015-05-18 2011
>> To: Kirill Katsnelson
>> Cc: kal...@li...
>> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>>
>> Hm.
>> If the only issue is the int32and int64 definitions, I think a cleaner
>> fix would be to apply a patch to OpenFst to make it use the same
>> definitions that Kaldi uses (which is the "proper" way to do it).
>> Dan
>>
>>
>> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson
>> <kir...@sm...> wrote:
>> > I am not exactly "moving" main() into namespace kaldi: there is
>> another, global main that calls kaldi::main(). The kaldi::main() can be
>> named anything, and also I do not think the standard prohibits defining
>> functions called main in other namespaces.
>> >
>> > There are at least two ways to deal with the bug we discussed a few
>> days ago:
>> > 1. Move everything into namespace kaldi. In this case, the namespace-
>> local definitions (e. g. kaldi::int64) always win. Indeed, I am adding
>> a trivial main() that calls kaldi::main() in each program.
>> > 2. Declare all used types explicitly. This is what I did in the
>> couple files there, see the long banners of the using statements.
>> Simply "using namespace kaldi" does not cut it.
>> >
>> > Which of the two ways to select is a question I do not have much
>> opinion on.
>> >
>> > The error I am getting is about functions taking kaldi and openfst's
>> declared types int32 and int64 by pointer or by reference being
>> different and incompatible. I do not remember the exact message, but I
>> can easily roll back the change and see, if it would make more sense.
>> >
>> > -kkm
>> >
>> >> -----Original Message-----
>> >> From: Daniel Povey [mailto:dp...@gm...]
>> >> Sent: 2015-05-18 1944
>> >> To: Kirill Katsnelson
>> >> Cc: kal...@li...
>> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>> >>
>> >> Thanks a lot for these.
>> >> Yenda will deal with the checking-in issues.
>> >> Generally speaking I like your patches, but I'll just reiterate here
>> >> some comments I made on github:
>> >> I'm not happy with the way you worked around the MSVC compiler bug
>> by
>> >> moving main() into namespace kaldi. I believe this is not allowed,
>> >> e.g. see here http://stackoverflow.com/questions/3956678/main-in-
>> >> namespace,
>> >> and even if it were allowed it seems very wrong to me; and I doubt
>> it
>> >> would compile on all platforms. I'm OK to deal with MSVC's
>> >> brokenness by adding various #ifdefs, but actually breaking Kaldi
>> >> code is where I draw the line. I'm sure there must be less
>> >> heavyweight ways to deal with this problem? I don't know what error
>> >> message it was that you got, that you are trying to get rid of?
>> >>
>> >>
>> >> Dan
>> >>
>> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson
>> >> <kir...@sm...> wrote:
>> >> > I have collected all my source changes into 4 separate commits in
>> >> > my
>> >> git fork. Please review the changes at the following links:
>> >> >
>> >> > The first change is trivial, but is necessary for the whole rig to
>> >> work properly. EOL conventions are hard to fix later and cause the
>> >> most confusion in version control.
>> >> > https://github.com/kaldi-asr/kaldi/commit/bba053
>> >> >
>> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE
>> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d
>> >> >
>> >> > This is a change to fix the apparent MSVC bug with namespace
>> >> > resolution in template expansion
>> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7
>> >> >
>> >> > And the last deals with proper I/O binarization under Windows, and
>> >> Cygwin path conversions.
>> >> > The change depends on the 2nd from top above.
>> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3
>> >> >
>> >> > There are also changes to openfst files and headers, but I do not
>> >> know how to deal with them:
>> >> > - Check in the patches to be applied on top of existing patches?
>> >> > - Provide pre-build binaries?
>> >> > - Check in complete sources as part of kaldi repo?
>> >> >
>> >> > And there are build scripts, coming soon.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > -kkm
>> >> >
>> >> > ------------------------------------------------------------------
>> -
>> >> > --
>> >> -
>> >> > -------- 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
>> >> > 50+ you
>> >> > Actionable Insights Deep dive visibility with transaction tracing
>> >> > using APM Insight.
>> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> >> > _______________________________________________
>> >> > Kaldi-developers mailing list
>> >> > Kal...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
|
|
From: Kirill K. <kir...@sm...> - 2015-05-19 20:31:03
|
I am going back to reproduction the compile error in MSVC. I am using bin/phones-to-prons as a simple example and have reduced the module to the following exact lines:
#include "fst/fstlib.h"
#include "fstext/fstext-lib.h"
int main(int argc, char *argv[]) {
using namespace kaldi;
fst::VectorFst<fst::StdArc> phn2word;
fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true); // line 6
}
The error message follows. Only MSVC reports it, the Intel compiler has no problem here:
C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/script/print-impl.h(77): error C2872: 'int64' : ambiguous symbol [C:\projects\kaldi\kaldi\msbuild\bin\kaldi-bin.kwproj]
could be 'C:\projects\kaldi\kaldi\extlibs\openfstwin-1.3.1\include\fst/types.h(31) : int64_t int64'
or 'C:\projects\kaldi\kaldi\src\base/kaldi-types.h(48) : kaldi::int64'
..\../src/bin/phones-to-prons.cc(6) : see reference to class template instantiation 'fst::FstPrinter<fst::StdArc>' being compiled
The line print-impl.h(77), containing the reportedly ambiguous symbol, is essentially this:
namespace fst {
template <class A> class FstPrinter {
void PrintId(int64 id, const SymbolTable *syms, const char *name) const { // Line 77
}
};
}
This is indeed a compiler bug. The int64 does not even come from a template parameter, and is unambiguously ::int64 in this scope, already defined in an fst header.
Now, you would think that the template is expanded in the lexical scope of invocation, and thus preventing kaldi::int64 from being known as just int64 at this point would be the fix. Yes it is a fix indeed, but also is putting everything into the kaldi namespace. This compiles without an error (then the linker complains about the missing _main, but this is not a problem at this point):
#include "fst/fstlib.h"
#include "fstext/fstext-lib.h"
namespace kaldi {
int main(int argc, char *argv[]) {
fst::VectorFst<fst::StdArc> phn2word;
fst::FstPrinter<fst::StdArc> fstprinter(phn2word, NULL, NULL, NULL, false, true);
}
}
Why this works I do not know. Perhaps, kaldi::int64 is used in the template expansion. But it is also a fix (or, better put, a workaround).
I agree that the fst library goes way too far when defining global types int64 and friends (fst/types.h). But I do not know if it is possible to change at this point. If it is redefined as "fst::int64", kaldi is going to have trouble in modules having both "using namespace kaldi" and "using namespace fst", I think.
An amazingly ugly fix would be to define int64 as an alias to kaldi::int64 etc., and then #define FST_LIB_TYPES_H__ before including fst headers, thus preventing fst's definitions. I certainly would not like to depend on an internal detail of the fst library though.
-kkm
> -----Original Message-----
> From: Daniel Povey [mailto:dp...@gm...]
> Sent: 2015-05-18 2011
> To: Kirill Katsnelson
> Cc: kal...@li...
> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
>
> Hm.
> If the only issue is the int32and int64 definitions, I think a cleaner
> fix would be to apply a patch to OpenFst to make it use the same
> definitions that Kaldi uses (which is the "proper" way to do it).
> Dan
>
>
> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson
> <kir...@sm...> wrote:
> > I am not exactly "moving" main() into namespace kaldi: there is
> another, global main that calls kaldi::main(). The kaldi::main() can be
> named anything, and also I do not think the standard prohibits defining
> functions called main in other namespaces.
> >
> > There are at least two ways to deal with the bug we discussed a few
> days ago:
> > 1. Move everything into namespace kaldi. In this case, the namespace-
> local definitions (e. g. kaldi::int64) always win. Indeed, I am adding
> a trivial main() that calls kaldi::main() in each program.
> > 2. Declare all used types explicitly. This is what I did in the
> couple files there, see the long banners of the using statements.
> Simply "using namespace kaldi" does not cut it.
> >
> > Which of the two ways to select is a question I do not have much
> opinion on.
> >
> > The error I am getting is about functions taking kaldi and openfst's
> declared types int32 and int64 by pointer or by reference being
> different and incompatible. I do not remember the exact message, but I
> can easily roll back the change and see, if it would make more sense.
> >
> > -kkm
> >
> >> -----Original Message-----
> >> From: Daniel Povey [mailto:dp...@gm...]
> >> Sent: 2015-05-18 1944
> >> To: Kirill Katsnelson
> >> Cc: kal...@li...
> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly)
> >>
> >> Thanks a lot for these.
> >> Yenda will deal with the checking-in issues.
> >> Generally speaking I like your patches, but I'll just reiterate here
> >> some comments I made on github:
> >> I'm not happy with the way you worked around the MSVC compiler bug
> by
> >> moving main() into namespace kaldi. I believe this is not allowed,
> >> e.g. see here http://stackoverflow.com/questions/3956678/main-in-
> >> namespace,
> >> and even if it were allowed it seems very wrong to me; and I doubt
> it
> >> would compile on all platforms. I'm OK to deal with MSVC's
> >> brokenness by adding various #ifdefs, but actually breaking Kaldi
> >> code is where I draw the line. I'm sure there must be less
> >> heavyweight ways to deal with this problem? I don't know what error
> >> message it was that you got, that you are trying to get rid of?
> >>
> >>
> >> Dan
> >>
> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson
> >> <kir...@sm...> wrote:
> >> > I have collected all my source changes into 4 separate commits in
> >> > my
> >> git fork. Please review the changes at the following links:
> >> >
> >> > The first change is trivial, but is necessary for the whole rig to
> >> work properly. EOL conventions are hard to fix later and cause the
> >> most confusion in version control.
> >> > https://github.com/kaldi-asr/kaldi/commit/bba053
> >> >
> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE
> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d
> >> >
> >> > This is a change to fix the apparent MSVC bug with namespace
> >> > resolution in template expansion
> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7
> >> >
> >> > And the last deals with proper I/O binarization under Windows, and
> >> Cygwin path conversions.
> >> > The change depends on the 2nd from top above.
> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3
> >> >
> >> > There are also changes to openfst files and headers, but I do not
> >> know how to deal with them:
> >> > - Check in the patches to be applied on top of existing patches?
> >> > - Provide pre-build binaries?
> >> > - Check in complete sources as part of kaldi repo?
> >> >
> >> > And there are build scripts, coming soon.
> >> >
> >> > Thanks,
> >> >
> >> > -kkm
> >> >
> >> > ------------------------------------------------------------------
> -
> >> > --
> >> -
> >> > -------- 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
> >> > 50+ you
> >> > Actionable Insights Deep dive visibility with transaction tracing
> >> > using APM Insight.
> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> > _______________________________________________
> >> > Kaldi-developers mailing list
> >> > Kal...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
|
|
From: Daniel P. <dp...@gm...> - 2015-05-19 19:56:35
|
Kirill, I think the main use-case for Kaldi on windows is where people want to use Kaldi as a library to build a speech recognition application. I don't think we intend for those types of applications to use pipes; things would get very ugly if they were used in an application. In general we'd like as much of the code as possible to work correctly when compiled in MSVC, to avoid people getting freaked out by compiler errors when they try to compile the project. However, supporting Kaldi training with powershell is something we do not want. Powershell is not very friendly to pipes of raw data, and there are so many things in Kaldi scripts that would need to be replicated in powershell... it would get extremely painful, and no-one but you has expressed any interest in doing this; there simply isn't demand. We don't need to bend over backwards to support running binaries compiled in MSVC and running in cygwin. If someone is serious about training models with Kaldi they can just use Linux, and save themselves a lot of pain; and if they really want to train on Windows they can compile Kaldi with cygwin. So if there are any easy fixes that will enable this, we are happy to apply them, but we're not going to put a lot of code into Kaldi to make Windows-based training possible. I think I'm OK with getting rid of some of the older hacks and #ifdefs that we introduced to support older MSVC versions, as long as we still compile with fairly recent versions of MSVC (I don't really know what people are still using, though). Dan >> a) we should figure out what versions of MSVC we plan to "support'. For >> example stdint.h is either not supported at all or supported only in >> the most recent versions of the compiler. We should issue compile-time >> warning/error if the version of compiler (probably value of _MSC_VER) >> is not supported > > Agreed entirely. Currently, I have tested the build under VS2013 and Intel XE 2015. Do you think we should also support other versions? I can easily try VS2012, probably later this week. > >> b) I'm hesitant to accept your stance "we are relying on cygwin". >> Cygwin will be definitely necessary for running the egs, but kaldi >> development and especially development using kaldi libs should not rely >> on cygwin. > > Ah, I believe I see where our misunderstanding stems from. What I mean is that the kaldi as a toolkit does depend on Cygwin. It would require an insane amount of work to port the scripts to a Windows-only interpreter (e. g., powershell or cmd), followed by futile effort to support them and keep in-sync. I hope we are on the same page here. > > As for building kaldi in native Windows, I agree that the build process should not depend on Cygwin. Currently I am using only MSBuild and Powershell. > >> We should facilitate developement of "clean" windows applications >> without needing cygwin runtime to be installed. I actually think it >> would be nice of someone would be willing to contribute some windows >> example (I'm thinking of voxforge or yesno) -- either in powershell) or >> a GUI app, that could take files from kaldi-asr.org and decode a wav or >> a online speech from a microphone. > > Very good point. Kaldi is not only a toolkit but also a set of libraries, that should be usable without Cygwin on Windows. > > To use windows pipes, we will probably have to detect whether we are running under bash, and, if not, use different popen() logic. Everything else is already ok, since Cygwin filenames are mapped one-way, so if you give a kaldi tool a Windows filename, it still works. > > I'll address your points on github separately. > > -kkm > ------------------------------------------------------------------------------ > 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-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Kirill K. <kir...@sm...> - 2015-05-19 19:42:31
|
> -----Original Message----- > From: Jan Trmal [mailto:jt...@gm...] > Sent: 2015-05-19 0139 > > a) we should figure out what versions of MSVC we plan to "support'. For > example stdint.h is either not supported at all or supported only in > the most recent versions of the compiler. We should issue compile-time > warning/error if the version of compiler (probably value of _MSC_VER) > is not supported Agreed entirely. Currently, I have tested the build under VS2013 and Intel XE 2015. Do you think we should also support other versions? I can easily try VS2012, probably later this week. > b) I'm hesitant to accept your stance "we are relying on cygwin". > Cygwin will be definitely necessary for running the egs, but kaldi > development and especially development using kaldi libs should not rely > on cygwin. Ah, I believe I see where our misunderstanding stems from. What I mean is that the kaldi as a toolkit does depend on Cygwin. It would require an insane amount of work to port the scripts to a Windows-only interpreter (e. g., powershell or cmd), followed by futile effort to support them and keep in-sync. I hope we are on the same page here. As for building kaldi in native Windows, I agree that the build process should not depend on Cygwin. Currently I am using only MSBuild and Powershell. > We should facilitate developement of "clean" windows applications > without needing cygwin runtime to be installed. I actually think it > would be nice of someone would be willing to contribute some windows > example (I'm thinking of voxforge or yesno) -- either in powershell) or > a GUI app, that could take files from kaldi-asr.org and decode a wav or > a online speech from a microphone. Very good point. Kaldi is not only a toolkit but also a set of libraries, that should be usable without Cygwin on Windows. To use windows pipes, we will probably have to detect whether we are running under bash, and, if not, use different popen() logic. Everything else is already ok, since Cygwin filenames are mapped one-way, so if you give a kaldi tool a Windows filename, it still works. I'll address your points on github separately. -kkm |
|
From: Jan T. <jt...@gm...> - 2015-05-19 08:39:25
|
Kirill, thanks for your work and patches. I mostly like those patches. However, I have expressed the concern about several things. I will summarize the concerns here. Those interested in details, please go to the github discussion. Also, please feel free to comment on the patches. I think reviewing patches and reading them is a great way how to start with kaldi development a) we should figure out what versions of MSVC we plan to "support'. For example stdint.h is either not supported at all or supported only in the most recent versions of the compiler. We should issue compile-time warning/error if the version of compiler (probably value of _MSC_VER) is not supported b) I'm hesitant to accept your stance "we are relying on cygwin". Cygwin will be definitely necessary for running the egs, but kaldi development and especially development using kaldi libs should not rely on cygwin. We should facilitate developement of "clean" windows applications without needing cygwin runtime to be installed. I actually think it would be nice of someone would be willing to contribute some windows example (I'm thinking of voxforge or yesno) -- either in powershell) or a GUI app, that could take files from kaldi-asr.org and decode a wav or a online speech from a microphone. I don;t mean to sound too negative --but I feel we (kaldi community) should discuss these thing and decide. All being said, I think the patches are good job. y. y. y. On Tue, May 19, 2015 at 5:59 AM, Kirill Katsnelson < kir...@sm...> wrote: > > Actually on second thoughts, there would be no point fixing this as a > > patch, because patches anyway can't be applied from Windows unless you > > have cygwin installed, which I guess we're not assuming. > > Just to set things straight, we definitely are relying on cygwin. Bash is > kaldi's glue in all recipes, and there is not much use for it without > Cygwin. > > The main impetus behind the port was the support of CUDA and Intel MKL. > Also, I thought that the use of Intel compiler would speed it up on latest > Intel's CPUs, but it did not help much in practice over MSVC--perhaps > because most of matrix code is converted into BLAS calls already. > > I am going to repro the original compiler's errors tonight. > > -kkm > > > ------------------------------------------------------------------------------ > 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-developers mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-developers > |
|
From: Kirill K. <kir...@sm...> - 2015-05-19 03:59:50
|
> Actually on second thoughts, there would be no point fixing this as a > patch, because patches anyway can't be applied from Windows unless you > have cygwin installed, which I guess we're not assuming. Just to set things straight, we definitely are relying on cygwin. Bash is kaldi's glue in all recipes, and there is not much use for it without Cygwin. The main impetus behind the port was the support of CUDA and Intel MKL. Also, I thought that the use of Intel compiler would speed it up on latest Intel's CPUs, but it did not help much in practice over MSVC--perhaps because most of matrix code is converted into BLAS calls already. I am going to repro the original compiler's errors tonight. -kkm |
|
From: Daniel P. <dp...@gm...> - 2015-05-19 03:59:34
|
BTW, the reason I'm not so enthused about using the OpenFst int32 is for dependency management- most directories in Kaldi are designed to have no dependency on OpenFst, and I prefer to keep it that way so they can be used for other purposes (e.g. use the matrix library by itself). If you are getting your Windows-compatible OpenFst version from Paul Dixon, maybe you would be able to persuade him to change the int32 in his repository to use the system headers. Dan On Mon, May 18, 2015 at 11:51 PM, Daniel Povey <dp...@gm...> wrote: > I was not planning to have the openfst fixed upstream (I spoke with > Mike Riley about this issue 1 to 2 years ago and he seemed agreeable > to doing it from the system headers, but it has not happened, so > there is no timeline on that)- instead I was planning to apply a patch > to the openfst code from the Makefile in tools/ - we already apply > patches to OpenFst, to resolve some other issues, so adding something > else to the patch should not be a big issue. > For Windows compilation it might be necessary to get OpenFst from > somewhere else, from someone e.g. Paul Dixon who got it to compile on > Windows, and of course the tools/ Makefile assumes Unix, so there > might need to be different mechanism for applying the patch. > Actually on second thoughts, there would be no point fixing this as a > patch, because patches anyway can't be applied from Windows unless you > have cygwin installed, which I guess we're not assuming. But there > might be an alternative way to fix it in whatever source we are > getting OpenFst from to compile on Windows. > Dan > > > On Mon, May 18, 2015 at 11:42 PM, Kirill Katsnelson > <kir...@sm...> wrote: >> Or maybe patch kaldi to use e. g. fst::int32 in place of system provided int32? Maybe not cleaner but easier, and will not introduce a dependency on openfst being above the version where the fix would be applied. >> >> -kkm >> >>> -----Original Message----- >>> From: Daniel Povey [mailto:dp...@gm...] >>> Sent: 2015-05-18 2011 >>> To: Kirill Katsnelson >>> Cc: kal...@li... >>> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >>> >>> Hm. >>> If the only issue is the int32and int64 definitions, I think a cleaner >>> fix would be to apply a patch to OpenFst to make it use the same >>> definitions that Kaldi uses (which is the "proper" way to do it). >>> Dan >>> >>> >>> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson >>> <kir...@sm...> wrote: >>> > I am not exactly "moving" main() into namespace kaldi: there is >>> another, global main that calls kaldi::main(). The kaldi::main() can be >>> named anything, and also I do not think the standard prohibits defining >>> functions called main in other namespaces. >>> > >>> > There are at least two ways to deal with the bug we discussed a few >>> days ago: >>> > 1. Move everything into namespace kaldi. In this case, the namespace- >>> local definitions (e. g. kaldi::int64) always win. Indeed, I am adding >>> a trivial main() that calls kaldi::main() in each program. >>> > 2. Declare all used types explicitly. This is what I did in the >>> couple files there, see the long banners of the using statements. >>> Simply "using namespace kaldi" does not cut it. >>> > >>> > Which of the two ways to select is a question I do not have much >>> opinion on. >>> > >>> > The error I am getting is about functions taking kaldi and openfst's >>> declared types int32 and int64 by pointer or by reference being >>> different and incompatible. I do not remember the exact message, but I >>> can easily roll back the change and see, if it would make more sense. >>> > >>> > -kkm >>> > >>> >> -----Original Message----- >>> >> From: Daniel Povey [mailto:dp...@gm...] >>> >> Sent: 2015-05-18 1944 >>> >> To: Kirill Katsnelson >>> >> Cc: kal...@li... >>> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >>> >> >>> >> Thanks a lot for these. >>> >> Yenda will deal with the checking-in issues. >>> >> Generally speaking I like your patches, but I'll just reiterate here >>> >> some comments I made on github: >>> >> I'm not happy with the way you worked around the MSVC compiler bug >>> by >>> >> moving main() into namespace kaldi. I believe this is not allowed, >>> >> e.g. see here http://stackoverflow.com/questions/3956678/main-in- >>> >> namespace, >>> >> and even if it were allowed it seems very wrong to me; and I doubt >>> it >>> >> would compile on all platforms. I'm OK to deal with MSVC's >>> >> brokenness by adding various #ifdefs, but actually breaking Kaldi >>> >> code is where I draw the line. I'm sure there must be less >>> >> heavyweight ways to deal with this problem? I don't know what error >>> >> message it was that you got, that you are trying to get rid of? >>> >> >>> >> >>> >> Dan >>> >> >>> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson >>> >> <kir...@sm...> wrote: >>> >> > I have collected all my source changes into 4 separate commits in >>> >> > my >>> >> git fork. Please review the changes at the following links: >>> >> > >>> >> > The first change is trivial, but is necessary for the whole rig to >>> >> work properly. EOL conventions are hard to fix later and cause the >>> >> most confusion in version control. >>> >> > https://github.com/kaldi-asr/kaldi/commit/bba053 >>> >> > >>> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE >>> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d >>> >> > >>> >> > This is a change to fix the apparent MSVC bug with namespace >>> >> > resolution in template expansion >>> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 >>> >> > >>> >> > And the last deals with proper I/O binarization under Windows, and >>> >> Cygwin path conversions. >>> >> > The change depends on the 2nd from top above. >>> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 >>> >> > >>> >> > There are also changes to openfst files and headers, but I do not >>> >> know how to deal with them: >>> >> > - Check in the patches to be applied on top of existing patches? >>> >> > - Provide pre-build binaries? >>> >> > - Check in complete sources as part of kaldi repo? >>> >> > >>> >> > And there are build scripts, coming soon. >>> >> > >>> >> > Thanks, >>> >> > >>> >> > -kkm >>> >> > >>> >> > ------------------------------------------------------------------ >>> - >>> >> > -- >>> >> - >>> >> > -------- 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 >>> >> > 50+ you >>> >> > Actionable Insights Deep dive visibility with transaction tracing >>> >> > using APM Insight. >>> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> >> > _______________________________________________ >>> >> > Kaldi-developers mailing list >>> >> > Kal...@li... >>> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Daniel P. <dp...@gm...> - 2015-05-19 03:51:54
|
I was not planning to have the openfst fixed upstream (I spoke with Mike Riley about this issue 1 to 2 years ago and he seemed agreeable to doing it from the system headers, but it has not happened, so there is no timeline on that)- instead I was planning to apply a patch to the openfst code from the Makefile in tools/ - we already apply patches to OpenFst, to resolve some other issues, so adding something else to the patch should not be a big issue. For Windows compilation it might be necessary to get OpenFst from somewhere else, from someone e.g. Paul Dixon who got it to compile on Windows, and of course the tools/ Makefile assumes Unix, so there might need to be different mechanism for applying the patch. Actually on second thoughts, there would be no point fixing this as a patch, because patches anyway can't be applied from Windows unless you have cygwin installed, which I guess we're not assuming. But there might be an alternative way to fix it in whatever source we are getting OpenFst from to compile on Windows. Dan On Mon, May 18, 2015 at 11:42 PM, Kirill Katsnelson <kir...@sm...> wrote: > Or maybe patch kaldi to use e. g. fst::int32 in place of system provided int32? Maybe not cleaner but easier, and will not introduce a dependency on openfst being above the version where the fix would be applied. > > -kkm > >> -----Original Message----- >> From: Daniel Povey [mailto:dp...@gm...] >> Sent: 2015-05-18 2011 >> To: Kirill Katsnelson >> Cc: kal...@li... >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >> >> Hm. >> If the only issue is the int32and int64 definitions, I think a cleaner >> fix would be to apply a patch to OpenFst to make it use the same >> definitions that Kaldi uses (which is the "proper" way to do it). >> Dan >> >> >> On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson >> <kir...@sm...> wrote: >> > I am not exactly "moving" main() into namespace kaldi: there is >> another, global main that calls kaldi::main(). The kaldi::main() can be >> named anything, and also I do not think the standard prohibits defining >> functions called main in other namespaces. >> > >> > There are at least two ways to deal with the bug we discussed a few >> days ago: >> > 1. Move everything into namespace kaldi. In this case, the namespace- >> local definitions (e. g. kaldi::int64) always win. Indeed, I am adding >> a trivial main() that calls kaldi::main() in each program. >> > 2. Declare all used types explicitly. This is what I did in the >> couple files there, see the long banners of the using statements. >> Simply "using namespace kaldi" does not cut it. >> > >> > Which of the two ways to select is a question I do not have much >> opinion on. >> > >> > The error I am getting is about functions taking kaldi and openfst's >> declared types int32 and int64 by pointer or by reference being >> different and incompatible. I do not remember the exact message, but I >> can easily roll back the change and see, if it would make more sense. >> > >> > -kkm >> > >> >> -----Original Message----- >> >> From: Daniel Povey [mailto:dp...@gm...] >> >> Sent: 2015-05-18 1944 >> >> To: Kirill Katsnelson >> >> Cc: kal...@li... >> >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >> >> >> >> Thanks a lot for these. >> >> Yenda will deal with the checking-in issues. >> >> Generally speaking I like your patches, but I'll just reiterate here >> >> some comments I made on github: >> >> I'm not happy with the way you worked around the MSVC compiler bug >> by >> >> moving main() into namespace kaldi. I believe this is not allowed, >> >> e.g. see here http://stackoverflow.com/questions/3956678/main-in- >> >> namespace, >> >> and even if it were allowed it seems very wrong to me; and I doubt >> it >> >> would compile on all platforms. I'm OK to deal with MSVC's >> >> brokenness by adding various #ifdefs, but actually breaking Kaldi >> >> code is where I draw the line. I'm sure there must be less >> >> heavyweight ways to deal with this problem? I don't know what error >> >> message it was that you got, that you are trying to get rid of? >> >> >> >> >> >> Dan >> >> >> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson >> >> <kir...@sm...> wrote: >> >> > I have collected all my source changes into 4 separate commits in >> >> > my >> >> git fork. Please review the changes at the following links: >> >> > >> >> > The first change is trivial, but is necessary for the whole rig to >> >> work properly. EOL conventions are hard to fix later and cause the >> >> most confusion in version control. >> >> > https://github.com/kaldi-asr/kaldi/commit/bba053 >> >> > >> >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE >> >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d >> >> > >> >> > This is a change to fix the apparent MSVC bug with namespace >> >> > resolution in template expansion >> >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 >> >> > >> >> > And the last deals with proper I/O binarization under Windows, and >> >> Cygwin path conversions. >> >> > The change depends on the 2nd from top above. >> >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 >> >> > >> >> > There are also changes to openfst files and headers, but I do not >> >> know how to deal with them: >> >> > - Check in the patches to be applied on top of existing patches? >> >> > - Provide pre-build binaries? >> >> > - Check in complete sources as part of kaldi repo? >> >> > >> >> > And there are build scripts, coming soon. >> >> > >> >> > Thanks, >> >> > >> >> > -kkm >> >> > >> >> > ------------------------------------------------------------------ >> - >> >> > -- >> >> - >> >> > -------- 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 >> >> > 50+ you >> >> > Actionable Insights Deep dive visibility with transaction tracing >> >> > using APM Insight. >> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> >> > _______________________________________________ >> >> > Kaldi-developers mailing list >> >> > Kal...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Kirill K. <kir...@sm...> - 2015-05-19 03:42:44
|
Or maybe patch kaldi to use e. g. fst::int32 in place of system provided int32? Maybe not cleaner but easier, and will not introduce a dependency on openfst being above the version where the fix would be applied. -kkm > -----Original Message----- > From: Daniel Povey [mailto:dp...@gm...] > Sent: 2015-05-18 2011 > To: Kirill Katsnelson > Cc: kal...@li... > Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) > > Hm. > If the only issue is the int32and int64 definitions, I think a cleaner > fix would be to apply a patch to OpenFst to make it use the same > definitions that Kaldi uses (which is the "proper" way to do it). > Dan > > > On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson > <kir...@sm...> wrote: > > I am not exactly "moving" main() into namespace kaldi: there is > another, global main that calls kaldi::main(). The kaldi::main() can be > named anything, and also I do not think the standard prohibits defining > functions called main in other namespaces. > > > > There are at least two ways to deal with the bug we discussed a few > days ago: > > 1. Move everything into namespace kaldi. In this case, the namespace- > local definitions (e. g. kaldi::int64) always win. Indeed, I am adding > a trivial main() that calls kaldi::main() in each program. > > 2. Declare all used types explicitly. This is what I did in the > couple files there, see the long banners of the using statements. > Simply "using namespace kaldi" does not cut it. > > > > Which of the two ways to select is a question I do not have much > opinion on. > > > > The error I am getting is about functions taking kaldi and openfst's > declared types int32 and int64 by pointer or by reference being > different and incompatible. I do not remember the exact message, but I > can easily roll back the change and see, if it would make more sense. > > > > -kkm > > > >> -----Original Message----- > >> From: Daniel Povey [mailto:dp...@gm...] > >> Sent: 2015-05-18 1944 > >> To: Kirill Katsnelson > >> Cc: kal...@li... > >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) > >> > >> Thanks a lot for these. > >> Yenda will deal with the checking-in issues. > >> Generally speaking I like your patches, but I'll just reiterate here > >> some comments I made on github: > >> I'm not happy with the way you worked around the MSVC compiler bug > by > >> moving main() into namespace kaldi. I believe this is not allowed, > >> e.g. see here http://stackoverflow.com/questions/3956678/main-in- > >> namespace, > >> and even if it were allowed it seems very wrong to me; and I doubt > it > >> would compile on all platforms. I'm OK to deal with MSVC's > >> brokenness by adding various #ifdefs, but actually breaking Kaldi > >> code is where I draw the line. I'm sure there must be less > >> heavyweight ways to deal with this problem? I don't know what error > >> message it was that you got, that you are trying to get rid of? > >> > >> > >> Dan > >> > >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson > >> <kir...@sm...> wrote: > >> > I have collected all my source changes into 4 separate commits in > >> > my > >> git fork. Please review the changes at the following links: > >> > > >> > The first change is trivial, but is necessary for the whole rig to > >> work properly. EOL conventions are hard to fix later and cause the > >> most confusion in version control. > >> > https://github.com/kaldi-asr/kaldi/commit/bba053 > >> > > >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE > >> > 2015 Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d > >> > > >> > This is a change to fix the apparent MSVC bug with namespace > >> > resolution in template expansion > >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 > >> > > >> > And the last deals with proper I/O binarization under Windows, and > >> Cygwin path conversions. > >> > The change depends on the 2nd from top above. > >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 > >> > > >> > There are also changes to openfst files and headers, but I do not > >> know how to deal with them: > >> > - Check in the patches to be applied on top of existing patches? > >> > - Provide pre-build binaries? > >> > - Check in complete sources as part of kaldi repo? > >> > > >> > And there are build scripts, coming soon. > >> > > >> > Thanks, > >> > > >> > -kkm > >> > > >> > ------------------------------------------------------------------ > - > >> > -- > >> - > >> > -------- 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 > >> > 50+ you > >> > Actionable Insights Deep dive visibility with transaction tracing > >> > using APM Insight. > >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > >> > _______________________________________________ > >> > Kaldi-developers mailing list > >> > Kal...@li... > >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Daniel P. <dp...@gm...> - 2015-05-19 03:10:53
|
Hm. If the only issue is the int32and int64 definitions, I think a cleaner fix would be to apply a patch to OpenFst to make it use the same definitions that Kaldi uses (which is the "proper" way to do it). Dan On Mon, May 18, 2015 at 11:05 PM, Kirill Katsnelson <kir...@sm...> wrote: > I am not exactly "moving" main() into namespace kaldi: there is another, global main that calls kaldi::main(). The kaldi::main() can be named anything, and also I do not think the standard prohibits defining functions called main in other namespaces. > > There are at least two ways to deal with the bug we discussed a few days ago: > 1. Move everything into namespace kaldi. In this case, the namespace-local definitions (e. g. kaldi::int64) always win. Indeed, I am adding a trivial main() that calls kaldi::main() in each program. > 2. Declare all used types explicitly. This is what I did in the couple files there, see the long banners of the using statements. Simply "using namespace kaldi" does not cut it. > > Which of the two ways to select is a question I do not have much opinion on. > > The error I am getting is about functions taking kaldi and openfst's declared types int32 and int64 by pointer or by reference being different and incompatible. I do not remember the exact message, but I can easily roll back the change and see, if it would make more sense. > > -kkm > >> -----Original Message----- >> From: Daniel Povey [mailto:dp...@gm...] >> Sent: 2015-05-18 1944 >> To: Kirill Katsnelson >> Cc: kal...@li... >> Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) >> >> Thanks a lot for these. >> Yenda will deal with the checking-in issues. >> Generally speaking I like your patches, but I'll just reiterate here >> some comments I made on github: >> I'm not happy with the way you worked around the MSVC compiler bug by >> moving main() into namespace kaldi. I believe this is not allowed, >> e.g. see here http://stackoverflow.com/questions/3956678/main-in- >> namespace, >> and even if it were allowed it seems very wrong to me; and I doubt it >> would compile on all platforms. I'm OK to deal with MSVC's brokenness >> by adding various #ifdefs, but actually breaking Kaldi code is where I >> draw the line. I'm sure there must be less heavyweight ways to deal >> with this problem? I don't know what error message it was that you >> got, that you are trying to get rid of? >> >> >> Dan >> >> On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson >> <kir...@sm...> wrote: >> > I have collected all my source changes into 4 separate commits in my >> git fork. Please review the changes at the following links: >> > >> > The first change is trivial, but is necessary for the whole rig to >> work properly. EOL conventions are hard to fix later and cause the most >> confusion in version control. >> > https://github.com/kaldi-asr/kaldi/commit/bba053 >> > >> > Compatibility changes for Windows cl (VS2013) and icl (Intel XE 2015 >> > Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d >> > >> > This is a change to fix the apparent MSVC bug with namespace >> > resolution in template expansion >> > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 >> > >> > And the last deals with proper I/O binarization under Windows, and >> Cygwin path conversions. >> > The change depends on the 2nd from top above. >> > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 >> > >> > There are also changes to openfst files and headers, but I do not >> know how to deal with them: >> > - Check in the patches to be applied on top of existing patches? >> > - Provide pre-build binaries? >> > - Check in complete sources as part of kaldi repo? >> > >> > And there are build scripts, coming soon. >> > >> > Thanks, >> > >> > -kkm >> > >> > --------------------------------------------------------------------- >> - >> > -------- 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-developers mailing list >> > Kal...@li... >> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
|
From: Kirill K. <kir...@sm...> - 2015-05-19 03:05:25
|
I am not exactly "moving" main() into namespace kaldi: there is another, global main that calls kaldi::main(). The kaldi::main() can be named anything, and also I do not think the standard prohibits defining functions called main in other namespaces. There are at least two ways to deal with the bug we discussed a few days ago: 1. Move everything into namespace kaldi. In this case, the namespace-local definitions (e. g. kaldi::int64) always win. Indeed, I am adding a trivial main() that calls kaldi::main() in each program. 2. Declare all used types explicitly. This is what I did in the couple files there, see the long banners of the using statements. Simply "using namespace kaldi" does not cut it. Which of the two ways to select is a question I do not have much opinion on. The error I am getting is about functions taking kaldi and openfst's declared types int32 and int64 by pointer or by reference being different and incompatible. I do not remember the exact message, but I can easily roll back the change and see, if it would make more sense. -kkm > -----Original Message----- > From: Daniel Povey [mailto:dp...@gm...] > Sent: 2015-05-18 1944 > To: Kirill Katsnelson > Cc: kal...@li... > Subject: Re: [Kaldi-developers] Windows patches to src/ (mostly) > > Thanks a lot for these. > Yenda will deal with the checking-in issues. > Generally speaking I like your patches, but I'll just reiterate here > some comments I made on github: > I'm not happy with the way you worked around the MSVC compiler bug by > moving main() into namespace kaldi. I believe this is not allowed, > e.g. see here http://stackoverflow.com/questions/3956678/main-in- > namespace, > and even if it were allowed it seems very wrong to me; and I doubt it > would compile on all platforms. I'm OK to deal with MSVC's brokenness > by adding various #ifdefs, but actually breaking Kaldi code is where I > draw the line. I'm sure there must be less heavyweight ways to deal > with this problem? I don't know what error message it was that you > got, that you are trying to get rid of? > > > Dan > > On Mon, May 18, 2015 at 8:54 PM, Kirill Katsnelson > <kir...@sm...> wrote: > > I have collected all my source changes into 4 separate commits in my > git fork. Please review the changes at the following links: > > > > The first change is trivial, but is necessary for the whole rig to > work properly. EOL conventions are hard to fix later and cause the most > confusion in version control. > > https://github.com/kaldi-asr/kaldi/commit/bba053 > > > > Compatibility changes for Windows cl (VS2013) and icl (Intel XE 2015 > > Update 3) https://github.com/kaldi-asr/kaldi/commit/1cc30d > > > > This is a change to fix the apparent MSVC bug with namespace > > resolution in template expansion > > https://github.com/kaldi-asr/kaldi/commit/f0f9e7 > > > > And the last deals with proper I/O binarization under Windows, and > Cygwin path conversions. > > The change depends on the 2nd from top above. > > https://github.com/kaldi-asr/kaldi/commit/5d2cc3 > > > > There are also changes to openfst files and headers, but I do not > know how to deal with them: > > - Check in the patches to be applied on top of existing patches? > > - Provide pre-build binaries? > > - Check in complete sources as part of kaldi repo? > > > > And there are build scripts, coming soon. > > > > Thanks, > > > > -kkm > > > > --------------------------------------------------------------------- > - > > -------- 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-developers mailing list > > Kal...@li... > > https://lists.sourceforge.net/lists/listinfo/kaldi-developers |
23 messages has been excluded from this view by a project administrator.