- fsa - lists.rwth-aachen.de

Compiling problems (RWTH FSA tool kit)
by sandeep kumar సందీప్ కుమార్ 22 Apr '09

22 Apr '09

Hi all, I have some compiling problems with RWTH FSA tool kit. (uname : Linux abu01 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux ) Following is the total make log. [ngoel@abu01 fsa-0.9.4]$ make ******************************************************************************** Project: The RWTH FSA Toolkit ******************************************************************************** Build host: abu01 Build date: Wed Apr 22 11:08:30 EDT 2009 Build directory: /home/ngoel/telephony/boda_work/fsa-0.9.4 Processor: x86_64 Operating system: linux Version: 0.9.4 - standard Profiling: none Compiler: ccache gcc / ccache g++ Preprocessor flags: -DSTANDARD -DBUILD="" -DPROC_x86_64 -DOS_linux -DARCH_linux_x86_64 -D__BASE_DIR__="/home/ngoel/telephony/boda_work/fsa-0.9.4" -D_GNU_SOURCE -I. -I./src -I/usr/include/libxml2 C compiler flags: -pipe -funsigned-char -fno-exceptions -pedantic -Wall -Wno-long-long -DHAS_64BIT -ffast-math -O2 -std=c99 C++ compiler flags: -pipe -funsigned-char -fno-exceptions -pedantic -Wall -Wno-long-long -DHAS_64BIT -ffast-math -O2 -fpermissive -std=c++98 Linker: g++ Linker flags: -lxml2 -lz -lm -lz -lm -rdynamic Installation directories: Base: Binaries: Includes: Libraries: ******************************************************************************** make -C src build make[1]: Entering directory `/home/ngoel/telephony/boda_work/fsa-0.9.4/src' make -C Core libSprintCore.linux-x86_64-standard.a make[2]: Entering directory `/home/ngoel/telephony/boda_work/fsa-0.9.4/src/Core' make[2]: Leaving directory `/home/ngoel/telephony/boda_work/fsa-0.9.4/src/Core' make[2]: Entering directory `/home/ngoel/telephony/boda_work/fsa-0.9.4/src/Core' compiling Application.cc Application.cc:220:2: warning: #warning is a GCC extension Application.cc:220:2: warning: #warning "This is a workaround for possible bug in LIBC 2.3.2. We are waiting for an answer on our bug report." compiling Assertions.cc compiling BinaryStream.cc BinaryStream.cc:20:2: warning: #warning is a GCC extension BinaryStream.cc:20:2: warning: #warning "CodeSmell: wrapper and file stream roles should be separated: BinaryWriter/Reader vs. BinaryStream" BinaryStream.cc:105: warning: specialization of ‘template<class T> bool Core::BinaryOutputStream::write(const T*, std::streamsize)’ in different namespace BinaryStream.hh:136: warning: from definition of ‘template<class T> bool Core::BinaryOutputStream::write(const T*, std::streamsize)’ BinaryStream.cc: In member function ‘bool Core::BinaryOutputStream::write(const T*, std::streamsize) [with T = bool]’: BinaryStream.cc:106: internal compiler error: in comptypes, at cp/typeck.c:947 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/cctulT0S.out file, please attach this to your bugreport. make[2]: *** [.build/linux-x86_64-standard/BinaryStream.o] Error 1 make[2]: Leaving directory `/home/ngoel/telephony/boda_work/fsa-0.9.4/src/Core' make[1]: *** [Core] Error 2 make[1]: Leaving directory `/home/ngoel/telephony/boda_work/fsa-0.9.4/src' make: *** [build] Error 2 -- Regards, B. Sandeep Kumar, M.Tech ECE/DSP IIT Guwahati. www.apptek.com

1 0

bug fix: random arc weights
by Markus Dreyer 13 Jun '07

13 Jun '07

I noticed a bug in fsa-0.9.4: when an XML file is read in which an arc has no weight specified then the weight will be uninitialized and may be a random value. The behavior occurred on an Intel(R) Xeon(TM) CPU 3.06GHz system, after compiling with gcc-3.4.4. For example, the arc weight in the src/Tools/Fsa/examples/closure-1.fsa machine is -1.792753, or -1.829887, different on every run, instead of 0. To fix the bug, insert the line arc_->weight_ = fsa_->semiring()->one(); in src/Fsa/StorageXml.cc, after line 97, so that you have arc_->output_ = Epsilon; arc_->weight_ = fsa_->semiring()->one(); --Markus

1 0

compiling problems
by Krishna M. Roskin 22 Feb '06

22 Feb '06

Hello, I have been unable to compile the library. I've tried with GCC 3.4.4 and GCC 4.0.2. I get this error message: BinaryStream.cc:105: warning: specialization of 'template<class T> bool Core::BinaryOutputStream::write(const T*, std::streamsize)' in different namespace BinaryStream.hh:136: warning: from definition of 'template<class T> bool Core::BinaryOutputStream::write(const T*, std::streamsize)' BinaryStream.cc: In member function 'bool Core::BinaryOutputStream::write(const T*, std::streamsize) [with T = bool]': BinaryStream.cc:105: internal compiler error: in comptypes, at cp/typeck.c:942 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. If I comment out those errors, I still get this: Parameter.cc:174: warning: extra ';' Parameter.cc:179: error: expected unqualified-id before ';' token Parameter.cc:180: error: expected unqualified-id before ';' token Parameter.cc:181: error: expected unqualified-id before ';' token Parameter.cc:182: error: expected unqualified-id before ';' token Parameter.cc:183: error: expected unqualified-id before ';' token Parameter.cc:184: error: expected unqualified-id before ';' token Parameter.cc:185: error: expected unqualified-id before ';' token Parameter.cc:187: error: expected unqualified-id before ';' token Parameter.cc:188: error: expected unqualified-id before ';' token Parameter.cc:189: error: expected unqualified-id before ';' token >From my understanding of the internal compiler error in the first error, is that it has so to do with the type checker failing when it tries to compare two types. It seems that both these errors have to do with template specilization. Any suggestions on what I can do to compile the code? Should I downgrade GCC to 3.2 (which is what you quote in the README)? -krish -- Krishna M. Roskin Center for Biomolecular Science and Engineering, UC Santa Cruz mailto:krish@soe.ucsc.edu http://www.soe.ucsc.edu/~krish/

3 4

reading att-format problem ?
by Owen TN 20 Sep '05

20 Sep '05

Hi, I tried FSA with very small examples and find out that: 1. FSA can not read the acceptor in AT&T format. Does it just only work with transducer in AT&t format ? Or am I wrong ? - suppose I have the file name "test.fst" which contains: 0 1 A 0 2 B 0 3 C 1 0 eps 1 2 B 1 3 C 1 2 0 eps 2 3 C 2 3 - RUN "fsa.linux-x86_64-standard att:testlm.def.DEF infor". The following message appeared: PROGRAM DEFECTIVE: precondition type() == TypeTransducer violated in virtual void Fsa::StorageAutomaton::setOutputAlphabet(Fsa::ConstAlphabetRef) file Storage.cc line 63 stack trace (innermost first): #2 fsa.linux-x86_64-standard [0x483b53] #3 fsa.linux-x86_64-standard(_ZN3Fsa7readAttEPNS_16StorageAutomatonERSi+0x81d) [0x45ea3d] #4 fsa.linux-x86_64-standard(_ZN3Fsa4readEPNS_16StorageAutomatonERKSs+0xf1) [0x45d3e1] #5 fsa.linux-x86_64-standard(_ZN3Fsa4readERKSsN4Core3RefIKNS_8SemiringEEE+0x2c2) [0x45dd02] #6 fsa.linux-x86_64-standard(_ZN7FsaTool4mainERKSt6vectorISsSaISsEE+0x262f) [0x43eaff] #7 fsa.linux-x86_64-standard(_ZN4Core11Application3runERKSt6vectorISsSaISsEE+0x25) [0x48ece5] #8 fsa.linux-x86_64-standard(_ZN4Core11Application4mainEiPPc+0x886) [0x48ffb6] #9 /lib64/tls/libc.so.6(__libc_start_main+0xdb) [0x38e3e1c4bb] #10 fsa.linux-x86_64-standard(__gxx_personality_v0+0xd2) [0x437dca] Aborted 2. Problem with "epsilon edges" ? I found that, with a WFST in AT&T format, FSA correctly treats the symbol "eps" as an epsilon label. However, with a FST (without weights on edges), FSA correctly treats "eps" of the output label as an epsilon label but "eps" of the input label is kept as the distinct label. Here is an example: WITH WFST: Suppose we have a WFST file named DICT1.def 0 1 eps eps 0 1 2 a eps 0 2 3 a eps 0 3 4 a eps 0 4 5 eps A 0 0 6 eps eps 0 6 7 a eps 0 7 8 a eps 0 8 9 b eps 0 9 5 eps B 0 0 10 eps eps 0 10 11 a eps 0 11 12 a eps 0 12 13 c eps 0 13 5 eps C 0 5 - RUN: fsa.linux-x86_64-standard att:DICT1.def write,file=DICT1.fsa We have DICT1.fsa as we expected: <?xml version="1.0" encoding="UTF8"?> <fsa type="transducer" semiring="tropical" initial="0"> <input-alphabet> <symbol index="0">a</symbol> <symbol index="1">b</symbol> <symbol index="2">c</symbol> </input-alphabet> <output-alphabet> <symbol index="0">A</symbol> <symbol index="1">B</symbol> <symbol index="2">C</symbol> </output-alphabet> <state id="0"> <arc target="1"></arc> <arc target="6"></arc> <arc target="10"></arc> </state> <state id="10"> <arc target="11"><in>0</in></arc> </state> <state id="11"> <arc target="12"><in>0</in></arc> </state> <state id="12"> <arc target="13"><in>2</in></arc> </state> <state id="13"> <arc target="5"><out>2</out></arc> </state> <state id="5"><final/> </state> <state id="6"> <arc target="7"><in>0</in></arc> </state> <state id="7"> <arc target="8"><in>0</in></arc> </state> <state id="8"> <arc target="9"><in>1</in></arc> </state> <state id="9"> <arc target="5"><out>1</out></arc> </state> <state id="1"> <arc target="2"><in>0</in></arc> </state> <state id="2"> <arc target="3"><in>0</in></arc> </state> <state id="3"> <arc target="4"><in>0</in></arc> </state> <state id="4"> <arc target="5"><out>0</out></arc> </state> </fsa> - But with FST named DICT2.def: 0 1 eps eps 1 2 a eps 2 3 a eps 3 4 a eps 4 5 eps A 0 6 eps eps 6 7 a eps 7 8 a eps 8 9 b eps 9 5 eps B 0 10 eps eps 10 11 a eps 11 12 a eps 12 13 c eps 13 5 eps C 5 and RUN: fsa.linux-x86_64-standard att:DICT2.def write,file=DICT2.fsa then we've got the unexpected result: DICT2.fsa contained: <?xml version="1.0" encoding="UTF8"?> <fsa type="transducer" semiring="tropical" initial="0"> <input-alphabet> <symbol index="0">eps</symbol> <symbol index="1">a</symbol> <symbol index="2">b</symbol> <symbol index="3">c</symbol> </input-alphabet> <output-alphabet> <symbol index="0">A</symbol> <symbol index="1">B</symbol> <symbol index="2">C</symbol> </output-alphabet> <state id="0"> <arc target="1"><in>0</in></arc> <arc target="6"><in>0</in></arc> <arc target="10"><in>0</in></arc> </state> <state id="10"> <arc target="11"><in>1</in></arc> </state> <state id="11"> <arc target="12"><in>1</in></arc> </state> <state id="12"> <arc target="13"><in>3</in></arc> </state> <state id="13"> <arc target="5"><in>0</in><out>2</out></arc> </state> <state id="5"><final/> </state> <state id="6"> <arc target="7"><in>1</in></arc> </state> <state id="7"> <arc target="8"><in>1</in></arc> </state> <state id="8"> <arc target="9"><in>2</in></arc> </state> <state id="9"> <arc target="5"><in>0</in><out>1</out></arc> </state> <state id="1"> <arc target="2"><in>1</in></arc> </state> <state id="2"> <arc target="3"><in>1</in></arc> </state> <state id="3"> <arc target="4"><in>1</in></arc> </state> <state id="4"> <arc target="5"><in>0</in><out>0</out></arc> </state> </fsa> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[fsa-announce] ANNOUNCE fsa version 0.9.3
by Stephan Kanthak 12 Sep '05

12 Sep '05

Hi! I'm proud to announce version 0.9.3 of the RWTH FSA toolkit. It's a maintainance release this time that fixes 2 small compilation problems: * changed local handler in Core/Assertions from private to public, caused problems during compilation for Georg Stemmer <stemmer(a)itc.it> on gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) * fixed a small 64-bit linux compilation bug in Fsa/Semiring.cc I also apologize that the announcement of version 0.9.2 over a month ago did not go to both mailing lists. All users that experienced compilation problems due to Common C++ are strongly encouraged to try either version 0.9.2 or 0.9.3 as we removed the dependency on Common C++ from the package. As usual, the package can be obtained from the software page at I6, RWTH Aachen: http://www-i6.informatik.rwth-aachen.de/web/Software/index.html Cheers, Stephan Kanthak

1 0

Still a problem for compiling fsa 0.9.2 under fedora g++ (GCC) 3.4.3
by Owen TN 12 Sep '05

12 Sep '05

Dear, First of all, I would like to say congratulation for the new version of our FSA toolkit. I have tried to compile the new version in my computer but it seems not successful. As a very beginner of Linux, I could not fix it myseft. Please help me to solve the problem. Thanks in advance. Bellow is the message appeared on the screen. ------------------------------------------------------- ******************************************************************************** Project: The RWTH FSA Toolkit ******************************************************************************** Build host: glenscotia Build date: Mon Jul 25 16:19:59 CEST 2005 Build directory: /users/owen/Softs/fsa-0.9.2 Processor: intel Operating system: linux Version: - standard Profiling: none Compiler: gcc / g++ Preprocessor flags: -DSTANDARD -DBUILD="" -DPROC_intel -DOS_linux -DARCH_linux_intel -D__BASE_DIR__="/users/owen/Softs/fsa-0.9.2" -D_GNU_SOURCE -DTIMESTAMP -I. -I./src -I/usr/include/libxml2 C compiler flags: -pipe -funsigned-char -fno-exceptions -pedantic -Wall -Wno-long-long -march=i686 -ffast-math -O2 -std=c99 C++ compiler flags: -pipe -funsigned-char -fno-exceptions -pedantic -Wall -Wno-long-long -march=i686 -ffast-math -O2 -fpermissive -std=c++98 Linker: g++ Linker flags: -L/usr/lib -lxml2 -lz -lpthread -lm -lz -lm -rdynamic Installation directories: Base: Binaries: Includes: Libraries: ******************************************************************************** make -C src build which: no ccache in (I skipped some lines ....) make[1]: Entering directory `/users/owen/Softs/fsa-0.9.2/src' make -C Core libSprintCore.linux-intel-standard.a which: no ccache in (I skipped some lines ....) make[2]: Entering directory `/owen/Softs/fsa-0.9.2/src/Core' compiling BinaryStream.cc BinaryStream.cc:20:2: warning: #warning is a GCC extension BinaryStream.cc:20:2: warning: #warning "CodeSmell: wrapper and file stream roles should be separated: BinaryWriter/Reader vs. BinaryStream" BinaryStream.cc:105: warning: specialization of `template<class T> bool Core::BinaryOutputStream::write(const T*, std::streamsize)' in different namespace BinaryStream.hh:136: warning: from definition of `template<class T> bool Core::BinaryOutputStream::write(const T*, std::streamsize)' BinaryStream.cc: In member function `bool Core::BinaryOutputStream::write(const T*, std::streamsize) [with T = bool]': BinaryStream.cc:106: internal compiler error: in comptypes, at cp/typeck.c:932 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccNsG2mX.out file, please attach this to your bugreport. make[2]: *** [.build/linux-intel-standard/BinaryStream.o] Error 1 make[2]: Leaving directory `/users/owen/Softs/fsa-0.9.2/src/Core' make[1]: *** [Core] Error 2 make[1]: Leaving directory `/users/owen/Softs/fsa-0.9.2/src' make: *** [build] Error 2 ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 1

FSA compiled on Fedora Core 4.0
by Owen TN 04 Aug '05

04 Aug '05

Dear all, I compiled the FSA successully with Fedora Core 4.0, with some modifications from the source codes. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [fsa] compiling problems with fedora g++ (GCC) 3.4.3
by Owen TN 14 Jul '05

14 Jul '05

------------------------------------------------------------ Stephan wrote your problems are due to Common C++. It may be that you didn't have it installed. If your problem has time for 1 week then please wait until I've released the new version 0.9.2 which does not need Common C++ anymore. ------------------------------------------------------------ Stephan, Could you tell me when the new version of our FST software is available ? I am waiting for it for more than 2 weeks . Best regards, __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

compiling problems with fedora g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
by Owen TN 30 Jun '05

30 Jun '05

HI, I tried to compile fsa on my computer, which use fedora kernel and use g++ (GCC) 3.4.3 20050227 but unsuccessful. Could you please help me ? Below is the error appeared when I tried to compile: ------------------------------------------------------- Rules.make:99: warning: overriding commands for target `install' Makefile:43: warning: ignoring old commands for target `install' make: ccgnu2-config: Command not found make: ccgnu2-config: Command not found ******************************************************************************** Project: The RWTH FSA Toolkit ******************************************************************************** Build host: local Build date: Wed Jun 29 16:37:47 CEST 2005 Build directory: /users/owentn/fsa-0.9.1 Processor: intel Operating system: linux Version: - standard Profiling: none Compiler: gcc / g++ Preprocessor flags: -DSTANDARD -DBUILD="" -DPROC_intel -DOS_linux -DARCH_linux_intel -D__BASE_DIR__="/users/owentn/fsa-0.9.1" -D_GNU_SOURCE -DTIMESTAMP -I. -I./src -I/usr/include/libxml2 -I C compiler flags: -pipe -funsigned-char -fno-exceptions -pedantic -Wall -Wno-long-long -march=i686 -ffast-ma th -O2 -std=c99 C++ compiler flags: -pipe -funsigned-char -fno-exceptions -pedantic -Wall -Wno-long-long -march=i686 -ffast-ma th -O2 -fpermissive -std=c++98 Linker: g++ Linker flags: -L/usr/lib -lxml2 -lz -lpthread -lm -lz -lm -rdynamic Installation directories: Base: Binaries: Includes: Libraries: ******************************************************************************** make -C src build which: no ccache in make[1]: Entering directory `/users/owentn/fsa-0.9.1/src' ../Rules.make:99: warning: overriding commands for target `install' Makefile:30: warning: ignoring old commands for target `install' make -C Core libSprintCore.linux-intel-standard.a which: no ccache in make[2]: ccgnu2-config: Command not found make[2]: Entering directory `/users/owentn/fsa-0.9.1/src/Core' compiling Application.cc In file included from ../../src/Core/TextStream.hh:24, from XmlStream.hh:26, from Configuration.hh:21, from Configurable.hh:20, from Component.hh:21, from Application.hh:22, from Application.cc:21: ../../src/Core/Types.hh:79: error: an explicit specialization must be preceded by 'template <>' In file included from Channel.hh:21, from Component.hh:22, from Application.hh:22, from Application.cc:21: ../../src/Core/Hash.hh:19:30: ext/stl_hash_fun.h: No such file or directory In file included from Channel.hh:23, from Component.hh:22, from Application.hh:22, from Application.cc:21: ../../src/Core/Thread.hh:18:25: cc++/thread.h: No such file or directory In file included from Channel.hh:23, from Component.hh:22, from Application.hh:22, from Application.cc:21: ../../src/Core/Thread.hh:23: error: `ost' has not been declared ../../src/Core/Thread.hh:24: error: invalid use of undefined type `class Core::Mutex' ../../src/Core/Thread.hh:22: error: forward declaration of `class Core::Mutex' ../../src/Core/Thread.hh: In constructor `Core::Mutex::Mutex()': ../../src/Core/Thread.hh:26: error: `ost' has not been declared ../../src/Core/Thread.hh:26: error: type `class Core::Mutex' is not a direct base of `Core::Mutex' ../../src/Core/Thread.hh: In member function `void Core::Mutex::lock()': ../../src/Core/Thread.hh:27: error: `enterMutex' undeclared (first use this function) ../../src/Core/Thread.hh:27: error: (Each undeclared identifier is reported only once for each function it appears i n.) ../../src/Core/Thread.hh: In member function `void Core::Mutex::release()': ../../src/Core/Thread.hh:28: error: `leaveMutex' undeclared (first use this function) ../../src/Core/Thread.hh: At global scope: ../../src/Core/Thread.hh:31: error: `ost' has not been declared ../../src/Core/Thread.hh:31: error: invalid use of undefined type `class Core::MutexLock' ../../src/Core/Thread.hh:31: error: forward declaration of `class Core::MutexLock' ../../src/Core/Thread.hh:33: error: `ost' has not been declared ../../src/Core/Thread.hh: In constructor `Core::MutexLock::MutexLock(Core::Mutex&)': ../../src/Core/Thread.hh:33: error: `ost' has not been declared ../../src/Core/Thread.hh:33: error: type `class Core::MutexLock' is not a direct base of `Core::MutexLock' ../../src/Core/Thread.hh: At global scope: ../../src/Core/Thread.hh:36: error: `ost' has not been declared ../../src/Core/Thread.hh:36: error: invalid use of undefined type `class Core::Conditional' ../../src/Core/Thread.hh:36: error: forward declaration of `class Core::Conditional' ../../src/Core/Thread.hh:48: error: `ost' has not been declared ../../src/Core/Thread.hh:48: error: invalid use of undefined type `class Core::Thread' ../../src/Core/Thread.hh:48: error: forward declaration of `class Core::Thread' Application.cc:220:2: warning: #warning is a GCC extension Application.cc:220:2: warning: #warning "This is a workaround for possible bug in LIBC 2.3.2. We are waiting for an answer on our bug report." make[2]: *** [.build/linux-intel-standard/Application.o] Error 1 make[2]: Leaving directory `/users/owentn/fsa-0.9.1/src/Core' make[1]: *** [Core] Error 2 make[1]: Leaving directory `/users/owentn/fsa-0.9.1/src' make: *** [build] Error 2 ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

2 1

InvalidLabelId from cross product
by Roy Tromble 01 Jun '05

01 Jun '05

Fsa seemed to have no way of constructing the cross product of two acceptors, so I wrote a function that would do it. I think I must have handled the alphabets wrong, because when I concatenate such a transducer with others, I get arcs with 2147483647 for the label. Here's what I did: crossProduct is a function that maps the output labels of the first transducer and the input labels of the second transducer to epsilon, and then composes them. To map input labels and output labels to epsilon, I have two different classes extending ModifyAutomaton: EpsilonInputAutomaton replaces all of the arc input labels with Epsilon, and returns an empty Alphabet from getInputAlphabet. EpsilonOutputAutomaton does likewise with the outputs. Is there something obviously wrong with this that should lead to InvalidLabelId (which I think 2147483647 corresponds to) when I concatenate a transducer produced using my crossProduct function? Thanks, Roy

2 1