Page 2 of 3

I am currently investigating the ton of classes that implement the Sphinx interface "SearchSpace", or one of the three sub-interfaces. There are 19 in total and I am likely to have to add another one for the feature that I have in mind.

Anyway, I decided that I need something, preferably an Eclipse-plugin to visualize class dependencies, and there are actually a few options:

• X-Ray would probably do the job, but it doesn't work. Maybe I just don't know how to install it correctly.
• Byecycle have a great screencast on their page and more friendly installation instructions. It shows a dependency graph between classes and automatically and incrementally optimizes the graph layout. Infinitely. Using 20% of your processor(s). It's quite slow and it seems to be limited to only show dependencies within the package, while the dependencies I'm interested in often cross dependency boundaries (classes from different packages implementing an interface).

This has been programmed before, but here it is for you to see (and use):

IPATextField, a simple descendant of JTextField that will only accept phonetic input (either SAMPA or IPA if you know your uni codes by heart) and show IPA symbols.

You can try it out directly, as a main routine is included. It's even useful as your tiny copy-and-paste-IPA-editor.

Continuing from the last post, assume you want your OAA-agent to react on certain data changes. You setup a trigger with something like this:

oaaAddTrigger(data, otherSpeechEnd(_), oaaSolve(startTalking(), [reply(none)], [on(add), recurrence(whenever)])

Right? No! Well, yes but that's not enough. You have to make sure, that the data (otherSpeechEnd(X)) is already known to the facilitator.

So, in order for the trigger to work, you need two lines:

oaaAddData(otherSpeechEnd(_), []) 
aaAddTrigger(data, otherSpeechEnd(_), oaaSolve(startTalking(), [reply(none)], [on(add), recurrence(whenever)])

Very nasty behaviour, because the bug only occurs when you've restarted the facilitator and the data type is still unknown.

There is just one problem with the SRI language modeling toolkit: It doesn't come with a configure-scipt and the makefiles don't work out of the box. After an hour of searching through make output, we found out, that ubuntu does not use gawk but mawk as its standard awk implementation. Later on in the build process, this leads to weird errors.

I'll attach the changed common/Makefile.machine.i686 , so you (and I) don't have to redo the work later.

10000 messages à 1 IclINT: 217616 ms
10000 messages à 1 IclList with 320 IclINTs: 291248 ms
10000 messages à 320 bytes as IclDataQ: 781685 ms

Either I have to fix IclDataQ (unpacking the DataQ seems to be horribly slow) or we could omit using OAA for audio transmission and use a TCP stream directly.

Schonmal interessiert gewesen, warum und was bei der Ausführung so lange dauert?

Klar, beim eigenen Programm sollte ich es wissen, aber wenn ich jetzt Toolkit XYZ benutze, welche benutzte Operation ist dann besonders teuer?

Antwort darauf gibt ein Profiler, der das Laufzeitverhalten des Programms analysiert. Für Java macht das JRat ( http://jrat.sourceforge.net/quickstart.html#9.%20Examine%20the%20JRat%20Output ).

Sehr interessant, aber meine Frage, warum IclDataQ-Pakete dreimal so langsam zu entpacken sind als IclList-Pakete mit den entsprechenden Bytes drin, hat es auch nicht beantwortet. Blödes OAA...

After some struggling with CLASSPATHs and awkward type casting exceptions[1], I have successfully built my first OAA-agent! 

It's a data processor that lives in the sphinx-frontend and hands out samples (or other data, depending on where it is positioned in the frontend) to any other agent that asks[2].

Next step is to split the frontend-pipeline in two parts and connect them via OAA. On we go!

[1]: OAA-documentation does not say, that ICLList(java.utils.List args) only likes lists that contain ICLTerms...

[2]: Currently this means using oaa_shell to ask for a solution of the goal "audioData(X)" 

Page 2 of 3