Re: [Kaldi-users] Using SWIG to wrap kaldi for python

[Jan T. <af...@ce...>]

---------- Forwarded message ----------
From: "Jan Trmal" <jt...@gm...>
Date: Dec 12, 2013 9:41 AM
Subject: Re: [Kaldi-users] Using SWIG to wrap kaldi for python
To: "ondrej platek" <ond...@gm...>
Cc: "Dan Povey" <dp...@gm...>, "Danijel Korzinek" <
da...@pj...>, "Arnab Ghoshal" <a.g...@ed...>, "
kal...@li..." <kal...@li...>

BTW, AFAIK SWIG has another nice feature -- from the interface files (*.i)
it can generate wrappers for another languages, such as perl and java.
Didn't do it personaly (only python), so there might be
target-language-specific issues but I _think_ it should be pretty general.
The slightly unpleasant property of SWIG was that the wrappers were
"slightly on the wild side", I think it was because it was meant for pure C
interfaces in the beginning.
Y.


On Dec 11, 2013 8:56 PM, "Ondrej Platek" <ond...@gm...> wrote:

> I forget to mention that cffi is really good for interfacing C,
> but it is quite tedious to generate templated functions from C++ using
> cffi.
>
> The cython pyfst wrapper uses mustache templates to do the job
> of C++ preprocessor and I needed to modify only small pieces of code.
>
> Ondra
>
>
> On 11 December 2013 20:51, Ondrej Platek <ond...@gm...> wrote:
>
>> Hi,
>>
>> just a quick notice: I abandon cffi in favor to cython,
>> because I found really nice python wrapper around fst called pyfst
>> http://pyfst.github.io/
>>
>> Now, I am able to work with fst objects in Python (Currently only Log and
>> standard semiring are supported and I am always using VectorFst object).
>>
>> Cheers,
>>
>>  Ondra
>>
>>
>> On 11 December 2013 19:27, Daniel Povey <dp...@gm...> wrote:
>>
>>> Sorry, changing the list recipient to kaldi-users which is a real,
>>> existing list.
>>> Dan
>>>
>>>
>>>
>>> On Wed, Dec 11, 2013 at 1:16 PM, Daniel Povey <dp...@gm...> wrote:
>>>
>>>> Matthew,
>>>>
>>>> This is interesting.  People frequently ask me about how to wrap Kaldi
>>>> in scripting languages such as Python.
>>>> I'm cc'ing kaldi-discuss, so it gets archived for web search, and a
>>>> couple more people who I think may be interested.
>>>> For people's reference, the change you just checked in is here:
>>>>  http://sourceforge.net/p/kaldi/code/3297/
>>>> Ondrej Platek has another method, based on CFFI, that can be found
>>>> at  ^/sandbox/oplatek2/src/pykaldi
>>>> (where ^ is the top of the Kaldi source tree, i.e. svn://
>>>> svn.code.sf.net/p/kaldi/code/), and Danijel Korzinek has used Java,
>>>> which can be found at
>>>> ^/sandbox/korzinek/src/onlinebin/java-online-audio-client/
>>>> At this point, I'm not sure that I want to settle on one "official" way
>>>> to wrap Kaldi, I'd rather have people demonstrate various ways to do it and
>>>> people can choose what they want for their application.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On Wed, Dec 11, 2013 at 11:06 AM, Matthew Aylett <
>>>> mat...@gm...> wrote:
>>>>
>>>>> Hi all
>>>>>
>>>>> I've checked in some code which is a fairly vanilla use of SWIG to
>>>>> wrap kaldi functionality.
>>>>>
>>>>> The logic for this for me was to allow me to easily convert kaldi
>>>>> trees into HTK ones to test v HTS (not a long term functionality so maybe
>>>>> not  the best example).
>>>>>
>>>>> The idea was to wrap the io code to avoid rewriting scripts to read in
>>>>> and parse ascii outputs.
>>>>>
>>>>> In effect you give python function to load the object and traverse it
>>>>> as well as accessing info that is required.
>>>>>
>>>>> In order to do this I had to add some accesor function on event-map.h
>>>>>
>>>>> If you check out the idlak branch you will find:
>>>>>
>>>>> idlak-voice-build/pythonlib
>>>>>
>>>>> In here we have:
>>>>>
>>>>> Makefile:
>>>>>
>>>>> This is to wrap the api using SWIG. There is an issue of where it gets
>>>>> the binary swig from (versions can behave differently and error
>>>>> differently). At present it just picks it up from the path which is not
>>>>> ideal.
>>>>>
>>>>> Also it needs to find the python library. This varies by platfom (it
>>>>> is present on Mac but not completely obvious). I've only tested this for
>>>>> linux.
>>>>>
>>>>> idlakapi.i:
>>>>>
>>>>> This is the swig interface file. As you will see I don't do anything
>>>>> much in this apart from include headers. Although if you need to add
>>>>> callbacks etc there are ways of doing this here to take into account the
>>>>> python GlobalInterpreterLock.
>>>>>
>>>>> idlakapi.h:
>>>>>
>>>>> This si the API I am wrapping. In effect I am adding another layer
>>>>> which then indirectly accesses kaldi structures. I do this because I don't
>>>>> like wrapping .h files that haven't been written for the purpose. In my
>>>>> experience the dependencies get out of hand and you end up wrapping tons
>>>>> more stuff than you want. In this approach you add functions as you require
>>>>> them for real pythin (or java etc) applications.
>>>>>
>>>>> idlakapi.cc:
>>>>>
>>>>> This is the code which directly accesses the kaldi library functions.
>>>>>
>>>>> example.py:
>>>>>
>>>>> A little python program which reads in a context dependency tree and
>>>>> prints it out. In effect duplicating copy-tree --binary=false in.tree -
>>>>>
>>>>> (well almost it adds a CR at the end of the file)
>>>>>
>>>>> However this does it by traversing and accessing the EventMaps in the
>>>>> tree. Currently only works on binary trees.
>>>>>
>>>>> Questions:
>>>>>
>>>>> Why wrap at all?
>>>>>
>>>>> Well handy for things like realtime decoders. For me I find it  a very
>>>>> quick way of developing new stuff quickly because you can jump into python
>>>>> and use a whole load of available stuff and jump back to C++ then you write
>>>>> the C++ once it works.
>>>>>
>>>>> However it is a bit dangerous with kaldi because you have a nice
>>>>> command line style format and if mis-handled could lead to a much dirtier
>>>>> looking code base. The last thing I'd want to see is the way festival used
>>>>> Scheme. So an absolute ban on scary things like C++ code calling python
>>>>> programs.
>>>>>
>>>>> For the voice building process it will speed up development for me but
>>>>> if you guys want me to replace this with command line versions I can do so.
>>>>> Probably should in the long run anyway.
>>>>>
>>>>> Why wrap like this?
>>>>>
>>>>> Well I think SWIG is good because it allows you to wrap in multiple
>>>>> languages (even Perl ;-)
>>>>>
>>>>> I like it to be clear what is being wrapped and to keep it seperate
>>>>> from the main code base. I would suggest the same thing with producing a C
>>>>> API as well.
>>>>>
>>>>> But there are a lot of ways to skin this and its really up to the
>>>>> community to decide which they want to do it (if at all). Here is an
>>>>> example. If the consensus is to do it a different way I'm happy to change
>>>>> it but I think its useful to have a working example. I am by no means a
>>>>> Makefile expert either so this may need changing, it is basically assuming
>>>>> a load of static libraries and pretending the spi is like a bin program.
>>>>>
>>>>> By the way is anyone now keeping my branch up to date with the trunk?
>>>>> Arnab was doing so but he may not have time now. I can do it if you remind
>>>>> me what the commands are.
>>>>>
>>>>> Happy Xmas etc.
>>>>>
>>>>> Matthew
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 16, 2013 at 4:00 PM, ondrej platek <
>>>>> ond...@se...> wrote:
>>>>>
>>>>>> Thanks, for a very positive answer and useful information. I should
>>>>>> learn SWIG probably:)
>>>>>>
>>>>>> I am very interested in the example SWIG wrapping into idlak.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Ondra
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 16, 2013 at 4:27 PM, Matthew Aylett <
>>>>>> mat...@ce...> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> See below
>>>>>>>
>>>>>>>  I will add very quick notes about SWIG in following pros and cons
>>>>>>>> list:
>>>>>>>>
>>>>>>>> Pros:
>>>>>>>> - Multiple languages - not interesting for me
>>>>>>>>
>>>>>>> Faire enough but might be useful for kaldi community
>>>>>>>
>>>>>>>
>>>>>>>  - Once setup makefiles it works - interesting for me
>>>>>>>>
>>>>>>>
>>>>>>> Well that ain't so easy but there should be examples.  I have tended
>>>>>>> to use cmake to do the heavy lifting for me here but its not ideal and not
>>>>>>> used in kaldi.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Cons
>>>>>>>> - If the API C/C++ API is changed you need to changed on 3 places
>>>>>>>> (1 more place for *.i)
>>>>>>>>
>>>>>>>
>>>>>>> 1 place in the C API. The header file is included into SWIG not
>>>>>>> copied. However...
>>>>>>>
>>>>>>>
>>>>>>>    What worse if the API changes just in C++ and somebody forget to
>>>>>>>> update the interface file,
>>>>>>>>
>>>>>>>
>>>>>>> Yes this is an issue. But one that comes with a C API. So not
>>>>>>> specific to SWIG. Maintaining a seperate C API requires keeping it updated
>>>>>>> with the underlying C++ libs. This can be more problematic if you say
>>>>>>> define a struct once for an internal C header and then again for an
>>>>>>> external one (typically the compiler won't spot that either so you are in
>>>>>>> trouble).
>>>>>>>
>>>>>>> I would say that having the external C API is good discipline if we
>>>>>>> are serious at cross platform support but maybe no really an issue at this
>>>>>>> time.
>>>>>>>
>>>>>>>
>>>>>>>    I am unable to debug it (with cffi I successfully used gdb
>>>>>>>> already)  -> if you can I will be really interested.
>>>>>>>>
>>>>>>>
>>>>>>> No thats fine. You just gdb python and run the code in there. Can be
>>>>>>> messy if the bug is in the interface (very unusual) but fine for the
>>>>>>> underlying C code. Hence my use of this approach for rapid prototyping.
>>>>>>>
>>>>>>>
>>>>>>>  - Heavier dependancy than cffi-python (I guess it is arguable).
>>>>>>>>
>>>>>>>
>>>>>>> I think SWIG is self contained but could be wrong.
>>>>>>>
>>>>>>>
>>>>>>>    I use quite a lot of machines (5-6) without sudo access where is
>>>>>>>> very old Swig.
>>>>>>>>
>>>>>>>
>>>>>>> It is easy to download and compile locally without sudo. You just
>>>>>>> need it on your path to run.
>>>>>>>
>>>>>>>
>>>>>>>    I can install cffi very easily. Actually I wrote installation
>>>>>>>> script for it (True it requires Python headers and libffi. Hopefully the
>>>>>>>> libffi dependancy
>>>>>>>> disappears in future.)
>>>>>>>>
>>>>>>>> To conclude, the main objective against SWIG is,
>>>>>>>> that for developing interfaces (which changes quickly) SWIG is a
>>>>>>>> heavy choice for me.
>>>>>>>> With cffi-python it seems to me that I can work much faster.
>>>>>>>>
>>>>>>>
>>>>>>> I think if you are building a clean C API then it is easy to switch
>>>>>>> to SWIG at a later date if required anyway. I could use SWIG for idlak and
>>>>>>> we could compare and then go with whichever the community thought best in
>>>>>>> the long run.
>>>>>>>
>>>>>>> At some point I'll check in an example SWIG wrapping into idlak for
>>>>>>> people to look at.
>>>>>>>
>>>>>>> All the very best
>>>>>>>
>>>>>>>
>>>>>>> M.
>>>>>>>
>>>>>>>
>>>>>>>> Best
>>>>>>>>
>>>>>>>> Ondra
>>>>>>>>
>>>>>>>> PS: With cffi-python the docs is quite good but the included demos
>>>>>>>> gives you better idea how it can be used:
>>>>>>>> https://bitbucket.org/cffi/cffi/src/ab9e53ebcfb97eb8bee8d15cac57c3
>>>>>>>> f41d42f6f4/demo?at=default
>>>>>>>> PS2: I would like to learn how to use SWIG effectively. I was just
>>>>>>>> incapable of doing it so far :)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 16, 2013 at 2:54 PM, Matthew Aylett <
>>>>>>>> mat...@gm...> wrote:
>>>>>>>>       Hi
>>>>>>>> No prefer to be involved because will want to wrap Idlak too and
>>>>>>>> will need to do it the same way.
>>>>>>>>
>>>>>>>> I very much agree that if we wrap code it should be round a clear C
>>>>>>>> API. As such how it's wrapped becomes less of an issue. Wrapping C++ tends
>>>>>>>> to make
>>>>>>>> memory management less explicit.
>>>>>>>>
>>>>>>>> Doing this is most problematic if 1. you want to return anything
>>>>>>>> other than values or 2. if you need callbacks.
>>>>>>>>
>>>>>>>> On returning things like char * for example you need to decide on a
>>>>>>>> standard approach. What I do is make sure there is a structure or class
>>>>>>>> which manages
>>>>>>>> the memory, then have a formal python function to create it into a
>>>>>>>> python pointer and formally delete it when done. Then use C API calls to
>>>>>>>> access any
>>>>>>>> days.
>>>>>>>>
>>>>>>>> For callbacks the approach is more problematic because of things
>>>>>>>> like the Global Lock in Python.
>>>>>>>>
>>>>>>>> If you want to write the callback in python you end up with Python
>>>>>>>> calls C calls Python returns to C returns to Python. However I'm guessing
>>>>>>>> we don't use
>>>>>>>> callbacks much in kaldi (although if you write a realtime decoder
>>>>>>>> that might well change).
>>>>>>>>
>>>>>>>> Funnily enough Ondrej, your point about it all being in C as a
>>>>>>>> positive is not so much for me. Me experience of SWIG has been very good
>>>>>>>> (once you get the
>>>>>>>> makefiles to work). For standard C API just running it over the
>>>>>>>> header file is enough to generate everything you need. (Care required for 1
>>>>>>>> and yes SWIG
>>>>>>>> specific code required for 2.) So you don't generally need to know
>>>>>>>> anything about the SWIG language to wrap 99% of everything.
>>>>>>>>
>>>>>>>> Because it produces python versions of the functions you can use
>>>>>>>> command line completion (which I can't generally live without in python).
>>>>>>>>
>>>>>>>> However the best thing about it is that wrapping Java, C# is just
>>>>>>>> as easy (with the caveat about 2. I had to write java specific code for
>>>>>>>> callbacks in
>>>>>>>> particular to support the Android compiler.)
>>>>>>>>
>>>>>>>> However 90% of the work is making the C style API so if thats done
>>>>>>>> its easy enough to change to SWIG if you want to wrap Java etc.
>>>>>>>>
>>>>>>>> I can see where you are coming from but in my experience when you
>>>>>>>> wrap code it precisely because the user DOESN'T know C. Also the SWIG
>>>>>>>> wrapping is so
>>>>>>>> fast an easy I have used it often in development to try out C
>>>>>>>> routines and code and hacking pything for all the IO display stuff.
>>>>>>>>
>>>>>>>> So for SWIG an example my be the following in the header:
>>>>>>>>
>>>>>>>> typedef struct CPRC_buf CPRC_buf;
>>>>>>>>
>>>>>>>> /** Create a buffer. (if max_sz == -1 unlimited size)*/
>>>>>>>> extern CPRC_buf * CPRC_buf_new(int min_sz, int max_sz);
>>>>>>>> /** Remove a buffer and its associated memory. */
>>>>>>>> extern void CPRC_buf_delete(CPRC_buf * buf);
>>>>>>>> /** Add a string emsg to the buffer. */
>>>>>>>> extern void CPRC_buf_add(CPRC_buf *buf, const char * emsg);
>>>>>>>> /** Empty the buffer. */
>>>>>>>> extern const char * CPRC_buf_clear(CPRC_buf * buf);
>>>>>>>> /** Return a pointer to the contents of the buffer. */
>>>>>>>> extern const char * CPRC_buf_get(CPRC_buf * buf);
>>>>>>>>
>>>>>>>>
>>>>>>>> and the .i file:
>>>>>>>>
>>>>>>>> /*file: mymod.i */
>>>>>>>> %feature("autodoc", "1");
>>>>>>>>
>>>>>>>> %module mymod
>>>>>>>> %{
>>>>>>>> extern "C" {
>>>>>>>> #include "mymod.h"
>>>>>>>> }
>>>>>>>> %}
>>>>>>>>
>>>>>>>>
>>>>>>>> extern "C" {
>>>>>>>> #include "mymod.h"
>>>>>>>> }
>>>>>>>> %include "mymod.h"
>>>>>>>>
>>>>>>>>
>>>>>>>> Thats it. Add another function to the header it just automatically
>>>>>>>> wraps it.
>>>>>>>>
>>>>>>>> On saying all this the big issue is still the vanilla C API and
>>>>>>>> consistency. I just think you may have been a bit quick to dismiss SWIG.
>>>>>>>>
>>>>>>>> However I have a very poor grasp of most of the code you are
>>>>>>>> discussing so take my comments with that in mind.
>>>>>>>>
>>>>>>>> Very best
>>>>>>>>
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 16, 2013 at 9:39 AM, Vassil Panayotov <
>>>>>>>> vas...@gm...> wrote:
>>>>>>>>       Hi,
>>>>>>>>
>>>>>>>>       On Tue, Jul 16, 2013 at 1:34 AM, ondrej platek <
>>>>>>>> ond...@se...> wrote:
>>>>>>>>       > I am CCopying Vassil, because he might be interested in the
>>>>>>>> Python/C
>>>>>>>>       > interface of his online decoder.
>>>>>>>>
>>>>>>>> Ondra, thanks for adding me.
>>>>>>>>
>>>>>>>> I think I was somewhat confused at first about the scope of your
>>>>>>>> project.
>>>>>>>> I thought, that you are working on a fine grained Python API, which
>>>>>>>> gives direct access to the core classes in the online decoder. I
>>>>>>>> only
>>>>>>>> glanced through your code, but by looking at KaldiDecoderWrapper it
>>>>>>>> seems to me it's more like the user gets access to a commonly used
>>>>>>>> decoder configuration - i.e. KaldiDecoderWrapper::Setup() is
>>>>>>>> basically
>>>>>>>> the same as the main() functions of the sample binaries in
>>>>>>>> onlinebin/.
>>>>>>>> It seems to me, that in that regard, the functionality provided by
>>>>>>>> your code is very similar to that of Tanel Alumae's gst-plugin
>>>>>>>> (GStreamer has Python bindings). Just an observation - not saying it
>>>>>>>> as if it's something bad...
>>>>>>>>
>>>>>>>> By the way I would prefer to keep the core online decoder code as
>>>>>>>> compact as possible, and I think the code that is used only by the
>>>>>>>> extensions should be placed in their respective directories. I think
>>>>>>>> OnlineBlockSource should be placed in separate .h/.cc files, like
>>>>>>>> this
>>>>>>>> is the case with GstBufferSource (in gst-plugin/gst-audio-source.h)
>>>>>>>> .
>>>>>>>>
>>>>>>>> PS: Mathew, I know you are working mostly on Idlak, but since you
>>>>>>>> said
>>>>>>>> you have plenty of experience with wrapping code for interfacing
>>>>>>>> with
>>>>>>>> Python (and I don't have such experience) I decided against removing
>>>>>>>> you from this discussion, that I realize may not be very interesting
>>>>>>>> to you.
>>>>>>>>
>>>>>>>> Vassil
>>>>>>>>
>>>>>>>> > See the second half: Concrete example.
>>>>>>>> >
>>>>>>>> > What is CFFI?
>>>>>>>> > There is a CFFI library known for interfacing C to list.
>>>>>>>> > However, there is also a quite new Python library completely
>>>>>>>> unrelated to
>>>>>>>> > the lisp one.
>>>>>>>> > http://cffi.readthedocs.org/en/release-0.6/
>>>>>>>> > I liked it a lot since it interfaces the languages Python and C
>>>>>>>> without any
>>>>>>>> > intermediate language
>>>>>>>> > and it does it really elegant way.
>>>>>>>> >
>>>>>>>> > I used swig several times and is is a way, but not for me after
>>>>>>>> trying
>>>>>>>> > python-cffi.
>>>>>>>> > Mainly because swig intermediate language it is not standard
>>>>>>>> language with
>>>>>>>> > ready tools for debugging, lints and other helper stuff for
>>>>>>>> developing.
>>>>>>>> > Debugging the language interface is not really fun.
>>>>>>>> >
>>>>>>>> > I have to admit I am highly bias to python-cffi against swig.
>>>>>>>> > Mainly, because I am able to write things in Python-cffi very
>>>>>>>> easily which I
>>>>>>>> > was unable to do in Swig.
>>>>>>>> >
>>>>>>>> > I wrap the C++ interface by the C interface and the using the
>>>>>>>> python-cffi I
>>>>>>>> > access the C code from Python (and vice versa).
>>>>>>>> > I highly recommend to restrict the C++ to C interface, because the
>>>>>>>> > simplification with
>>>>>>>> >
>>>>>>>> > a) NO function overloading/virtual function tables (forced by the
>>>>>>>> C syntax)
>>>>>>>> > b) NO problems with mangling (if you define correct C interface)
>>>>>>>> >
>>>>>>>> > pays back very early.
>>>>>>>> >
>>>>>>>> > Note, that python-cffi is not able to interface C++ code and I am
>>>>>>>> quite glad
>>>>>>>> > for it.
>>>>>>>> > I guess it pays off use as simple as possible interface between
>>>>>>>> any
>>>>>>>> > languages also for Swig.
>>>>>>>> >
>>>>>>>> > =================
>>>>>>>> > Concrete example:
>>>>>>>> >
>>>>>>>> > Last week I was working on C interface for online-gmm-faster
>>>>>>>> decoder.
>>>>>>>> > I wrapped the functionality of the binary
>>>>>>>> > kaldi/trunk/src/online-gmm-decode-faster to C++ class
>>>>>>>> KaldiDecoderWrapper
>>>>>>>> > In addition I added C wrapper to the C++ class, so it supports C
>>>>>>>> linkage.
>>>>>>>> >
>>>>>>>> > Both the C and C++ interface can be found at
>>>>>>>> > kaldi/src/pykaldi/online-python-gmm-decode-faster.h
>>>>>>>> > either in sandbox/oplatek2 or at github
>>>>>>>> > (concretaly at :
>>>>>>>> > https://github.com/oplatek/pykaldi/blob/master/src/
>>>>>>>> pykaldi/online-python-gmm-decode-faster.h)
>>>>>>>> >
>>>>>>>> > How the python-cffi is used against the C linkage can be seen at
>>>>>>>> > OnlineDecoder:
>>>>>>>> > https://github.com/oplatek/pykaldi/blob/master/src/
>>>>>>>> pykaldi/decoders/kaldi_decoders.py#L50
>>>>>>>> >
>>>>>>>> > How to try the demo for OnlineDecoder which works for me under
>>>>>>>> Linux is
>>>>>>>> > described at:
>>>>>>>> > https://github.com/oplatek/pykaldi/tree/master/src/
>>>>>>>> pykaldi/binutils#how-to-run-the-demo
>>>>>>>> >
>>>>>>>> > Let me know if you have problems running the demo (I did not test
>>>>>>>> it well,
>>>>>>>> > but I wanted to reply with something real).
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > PS: Thanks Vassil for updating the online-audio interface. The
>>>>>>>> Read function
>>>>>>>> > without timetout makes better sense to me.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Mon, Jul 15, 2013 at 9:22 PM, Daniel Povey <dp...@gm...>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> Attaching Ondrej, he may have some comments.
>>>>>>>> >> Dan
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> On Mon, Jul 15, 2013 at 3:22 AM, Matthew Aylett <
>>>>>>>> mat...@gm...>
>>>>>>>> >> wrote:
>>>>>>>> >> > Hi
>>>>>>>> >> >
>>>>>>>> >> > CFFI -
>>>>>>>> >> > Common Foreign Function Interface, purports to be a portable
>>>>>>>> foreign
>>>>>>>> >> > function interface for Common Lisp.
>>>>>>>> >> >
>>>>>>>> >> > Eh?
>>>>>>>> >> >
>>>>>>>> >> > I have quite  lot of experience wrapping for Python. My advice
>>>>>>>> is:
>>>>>>>> >> >
>>>>>>>> >> > 1. Define a C API for wrapping. Avoid blanking wrapping of
>>>>>>>> headers with
>>>>>>>> >> > something like SWIG and define and justify which functions and
>>>>>>>> >> > structures
>>>>>>>> >> > should be wrapped. Do not wrap C++ objects (fine for dev work)
>>>>>>>> but very
>>>>>>>> >> > hard
>>>>>>>> >> > to control in a release environment if we ever want to release
>>>>>>>> kaldi as
>>>>>>>> >> > a
>>>>>>>> >> > binary library. In addition C API becomes basic API for such a
>>>>>>>> library
>>>>>>>> >> > avoiding C++ name mangling issues. Same API is then used to
>>>>>>>> wrap for C#
>>>>>>>> >> > Java
>>>>>>>> >> > etc.
>>>>>>>> >> >
>>>>>>>> >> > 2. Use something like SWIG to automatically generate
>>>>>>>> python/C#/Java API
>>>>>>>> >> > code
>>>>>>>> >> > from the C API.
>>>>>>>> >> >
>>>>>>>> >> > Of course when you find a stable way to do something you just
>>>>>>>> end up
>>>>>>>> >> > sticking with it so its perfectly possible there are better
>>>>>>>> ways and all
>>>>>>>> >> > this has been explored etc. (Arnab mentioned they had already
>>>>>>>> looked at
>>>>>>>> >> > SWIG
>>>>>>>> >> > but perhaps only in the context of wrapping already written
>>>>>>>> headers not
>>>>>>>> >> > based on writing a formal API header.) I'm guessing the CFFI
>>>>>>>> is more or
>>>>>>>> >> > less
>>>>>>>> >> > 1. above. Anyway happy to discuss my experiences with Ondrej
>>>>>>>> if its any
>>>>>>>> >> > help.
>>>>>>>> >> >
>>>>>>>> >> > Best
>>>>>>>> >> >
>>>>>>>> >> > M.
>>>>>>>> >>
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> > On Mon, Jul 15, 2013 at 6:27 AM, Daniel Povey <
>>>>>>>> dp...@gm...> wrote:
>>>>>>>> >> >>
>>>>>>>> >> >> Hi everyone,
>>>>>>>> >> >> I have been a bit lax in the last few weeks in sending out
>>>>>>>> updates.
>>>>>>>> >> >>
>>>>>>>> >> >> People might have noticed a change in the build process.  We
>>>>>>>> >> >> reorganized the setup to use dynamic libraries (so Kaldi does
>>>>>>>> not take
>>>>>>>> >> >> up so much space on disk) and to consolidate the shared parts
>>>>>>>> of the
>>>>>>>> >> >> Makefiles.  Thanks to Jan Trmal and Ondrej Platek who did
>>>>>>>> most of the
>>>>>>>> >> >> work.
>>>>>>>> >> >>
>>>>>>>> >> >> There have been some contributions from new people, regarding
>>>>>>>> various
>>>>>>>> >> >> ways to call Kaldi from other languages and frameworks:
>>>>>>>> >> >>
>>>>>>>> >> >>    - Tanel Alumae has created an example Kaldi plugin for the
>>>>>>>> >> >> GStreamer framework (see http://en.wikipedia.org/wiki/
>>>>>>>> GStreamer for
>>>>>>>> >> >> what that is).  see src/gst-plugin/
>>>>>>>> >> >>    - Danijel Korzinek has written some Java code that can
>>>>>>>> function as
>>>>>>>> >> >> a source of audio for the online decoder (there is some info
>>>>>>>> about
>>>>>>>> >> >> this at http://kaldi.sourceforge.net/online_programs.html)
>>>>>>>> >> >>    - Ondrej Platek is currently working on ways to call Kaldi
>>>>>>>> from
>>>>>>>> >> >> Python (this is not yet merged to the trunk, it's still in
>>>>>>>> >> >> ^/sandbox/oplatek).  It's based on "CFFI" (the Common Foreign
>>>>>>>> Function
>>>>>>>> >> >> Interface).
>>>>>>>> >> >>
>>>>>>>> >> >> Vassil Panayotov has been helping to test these additions and
>>>>>>>> has been
>>>>>>>> >> >> improving the online-decoding code.
>>>>>>>> >> >>
>>>>>>>> >> >> I have added a recipe for the Fisher English database.
>>>>>>>> >> >>
>>>>>>>> >> >> Gilles Boulianne improved the (time and memory) efficiency of
>>>>>>>> the
>>>>>>>> >> >> arpa2fst program.
>>>>>>>> >> >>
>>>>>>>> >> >> Karel Vesely continues to improve his neural-network training
>>>>>>>> setup
>>>>>>>> >> >> and the associated recipes.
>>>>>>>> >> >>
>>>>>>>> >> >> I had been hoping by now to have already committed changes
>>>>>>>> regarding
>>>>>>>> >> >> the use of ReLUs (rectified linear units) to my
>>>>>>>> neural-network setup,
>>>>>>>> >> >> but it's not ready yet.  ReLUs seemed to be helpful on RM and
>>>>>>>> WSJ-84,
>>>>>>>> >> >> but when I ran the recipe on the WSJ full SI284 data I didn't
>>>>>>>> see a
>>>>>>>> >> >> clear improvement.  Right now I am working on larger changes
>>>>>>>> to that
>>>>>>>> >> >> setup, including a rewrite of the scripts that's intended to
>>>>>>>> make the
>>>>>>>> >> >> training more efficient, but it will probably be at least a
>>>>>>>> few weeks
>>>>>>>> >> >> before I can check it in.  Also a CUDA-enabled version of my
>>>>>>>> parallel
>>>>>>>> >> >> neural network training setup is in the works (i.e. training
>>>>>>>> on
>>>>>>>> >> >> multiple CUDA cards) but this will be at least a couple
>>>>>>>> months.  I did
>>>>>>>> >> >> not get time (as I had hoped I would) to add any speaker-id
>>>>>>>> stuff to
>>>>>>>> >> >> Kaldi.
>>>>>>>> >> >>
>>>>>>>> >> >> Dan
>>>>>>>> >> >>
>>>>>>>> >> >> --
>>>>>>>> >> >>
>>>>>>>> >> >> ---
>>>>>>>> >> >> You received this message because you are subscribed to the
>>>>>>>> Google
>>>>>>>> >> >> Groups
>>>>>>>> >> >> "but10" group.
>>>>>>>> >> >> To unsubscribe from this group and stop receiving emails from
>>>>>>>> it, send
>>>>>>>> >> >> an
>>>>>>>> >> >> email to but...@go....
>>>>>>>> >> >> For more options, visit https://groups.google.com/
>>>>>>>> groups/opt_out.
>>>>>>>> >> >>
>>>>>>>> >> >>
>>>>>>>> >> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-users mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-users
>
>