In the ghost275.pl
AI we are consolidating the Russian-language knowledge-case (KB) directly below the English-language KB near the beginning of the MindBoot sequence, so that we may add a new item without complicating a future re-location of the Russian knowledge base.
We should probably stub in the RuIndicative() module, so that it will exist not only in our AI diagrams but also in the software itself.
When we start the AI out thinking in Russian, we have been encountering a bug that shows up with the second sentence of output. Perl complains about the use of "uninitialized value in concatenation or string" in the PsiDecay() module. To troubleshoot, we go through the PsiDecay concatenation of associative tags in the @Psy conceptual array and we replace the various variables one by one with a numeric value, to see if the complaint disappears. The complaint disappears when we replace the $k variable for the $hlc human-language code with a numeric value of one (1) instead of "en" for English or "ru" for Russian.
Perl continues to complain about uninitialized values when we have the Perlmind think in Russian, but not when it thinks in English. Therefore we know that the lurking bug is not in the PsiDecay() module or in the InStantiate() module, even though the bug manifests itself in those modules. We spent hours on each of the past two days searching for an elusive bug which must certainly be hiding in one or more of the Russian-language modules. Therefore it is time to isolate the bug by isolating the Russian-language modules. First let us look at the RuNounPhrase() module. We insert some diagnostic messages and we see that the bug manifests itself when program-flow goes back up to the RuThink() module which calls the PsiDecay() module.
Since we catch sight of the bug when PsiDecay() is called, let us temporarily insert some extra calls to PsiDecay() and see what happens. First we make an extra call to PsiDecay() from the end of RuNounPhrase(). Huh?! Now we get two complaints from Perl about uninitialized values showing up for a program line-number belonging to a concatenation in the PsiDecay() module. Let us also try an extra call to PsiDecay() from the RuVerbPhrase() module. We do so, and now we get three complaints from Perl about uninitialized values. However, the glitch does not seem to be occurring during the first call from RuIndicative() to RuNounPhrase(), but rather during or after the call to RuVerbPhrase(). For extra clarity, let us have the start of RuVerbPhrase() make a call to PsiDecay(). We do so, and there is no concomitant complaint from Perl about uninitialized values. Therefore, the subject-choosing part of RuNounPhrase() must not be the source of the problem, but the direct-object portion of RuNounPhrase() is still under suspicion.
As we go through RuVerbPhrase() and comment out the various concatenations, the complaint from Perl about uninitialized values suddenly disappears when we comment out the concatenation where Russian verbs are competing to be selected as the most active verb. We also notice that a comma seems to be missing at the end of the first line in the two-line concatenation. When we insert the missing comma and we do not comment out the concatenation, there are no further complaints from Perl about uninitialized values. Of course, we just spent three days wracking our brains, trying to figure out what was wrong, when the problem was one single missing comma. Now it is time to clean up the Perlmind code and upload it to the Web.