The MindForth Programming Journal (MFPJ) is both a tool in developing MindForth open-source artificial intelligence (AI) and an archival record of the history of how the AI Forthmind evolved over time.
MindForth came into being in 1998 on the Commodore Amiga 1000 computer as a port from the Amiga Mind.Rexx AI program, written in MVP-Forth from Mountain View Press. Around 1999, MindForth moved to a Windows 98 machine provided by Free-PC.com and to 16-bit FPC-Forth. Around 2001, MindForth moved to a Windows 95 Packard-Bell tower computer and to 32-bit Win32Forth. As the original author of Mind.Rexx and of MindForth, yesterday on 23 July 2014 I downloaded W32FOR42_671.zip onto the same Windows XP Acer Aspire One netbook which I have been using to develop the Russian Dushka AI program in JavaScript for MSIE. I unzipped W32FOR42_671.zip with my own legitimate copy of WinZip, which created a C:\WIN32FOR directory to hold all the decompressed files of Win32Forth. From the Web I downloaded the 24jan13A.F most current source code of MindForth and I saved it into the C:\WIN32FOR directory and as a text-file into a monthly C:\JUL01Y14\MFPJ directory on the Acer netbook.
I was able to get MindForth running on the Windows XP netbook by navigating with the "cd" (change directory) command into the C:\WIN32FOR directory where I typed "win32for.exe" and pressed "Enter"; then "fload 24jan13A.F" and the Enter-key; and finally "MainLoop" followed by the Enter-key. The AI Forthmind began to think its own thoughts on the screen, but the program soon crashed in its new environment, both during interaction with me and when allowed to think without human input. It was not a complete Snow Crash; but just as fatal with a pop-up message announcing "Exception # C0000005" and shutting down Win32Forth upon my clicking "Cancel" on the message. The naive and sentimental Forthcoder is not daunted or dismayed by such an AI-Mind-crash, but welcomes instead the chance to troubleshoot the AI and make it compatible with Windows XP. To debug MindForth, we will create a new version and seed it with diagnostic messages in order to find out just where and why the program is crashing with an "Exception" message. Long familiarity with MindForth causes me to suspect that there is probably a "boundary violation" where the software is trying to index one step beyond the limits of an array. We have noticed recently that searching Google for MindForth yields an auto-complete expansion of the search terms to "mindforth source code" -- an indication that Netizens have been looking for the free AI source code that we are working on right here and now. MindForth has also received a prominent mention at http://aihub.net/artificial-intelligence-lab-projects so we are motivated to make the best AI Mind that we can with MindForth and the other Mentifex AI programs.
Thurs.24.JUL.2014 -- Debugging Windows XP MindForthIn the C:\WIN32FOR directory, we enter win32for.exe to start running Win32Forth. Then we use the "File" drop-down menu and "Edit Forth File..." to click on "24jan13A.F" and "Open" it for editing and saving under a new name. Actually, we will save it immediately as "24jul14A.F" so as not to corrupt the old file by changing anything. First, however, we notice that the bottom of our WinViewX screen tells us that there are 5,173 lines of code with a size of 236,908 characters. Under the "File" drop-down menu we click on "Save File As.." and we enter "24jul14A.F" before clicking the "Save" button. We then close the WinViewX window because we want to test the new file before we proceed. We enter "fload 24jul14A.F" and we get the "ok" prompt which means that the file has successfully loaded into Win32Forth. When we enter "MainLoop" and observe without human input, the AI thinks about two thoughts and then stops with the "Exception # C0000005" pop-up message. This denouement occurs both in the default normal mode and in the Transcript mode that we invoke by pressing the Tab-key. It is time to start inserting diagnostic messages.
In the ThInk module we enter and reformulate a diagnostic message that we find commented-out in another mind-module. We forget to un-comment the code, so at first no diagnostics appear. Then we get the diagnostics, but with no change in program behavior -- it still crashes. But we see the light and we remember the Dao of debugging, that is, you figure out what modules the AI is calling and you insert diagnostics deeper and deeper into the program.
Let's see, the first part of AI thinking is to call the NounPhrase module, so let us diagnosticate NounPhrase. Aha! NounPhrase gives us some (meaningless?) diagnostics just before the Exception-crash, but the ThInk module does not. Therefore, Inspector Clouseau, the problem may lie within NounPhrase or within a module called by NounPhrase. By the way, instead of cluttering up this MFPJ journal entry with the actual diagnostic messages -- unless they become really important -- we can meta-publish the diagnostics simply by commenting them out but retaining them within the "mindforth source code" that we eventually publish on the Web. In that way, any interested party (corporate AI shop? national Ministry of AI? Ph.D. dissertation writer?) can see exactly how we have debugged the AI by inspecting the diagnostic messages that we will leave in for at least one iteration of releasing the code. So now let's plunk some diagnostics down in the VerbPhrase module in order to see if the AI thought processes are making it through NounPhrase and into VerbPhrase before the Exception-crash.
As the Forthmind thinks in English, we are getting diagnostic messages from both NounPhrase and VerbPhrase up until the dying thought of the AI, where NounPhrase reports something but VerbPhrase is silent, both in terms of output and in terms of diagnostics. So the crash could be occurring within the NounPhrase module. Therefore let us insert additional diagnostics towards the end of NounPhrase. We do so, but the software crashes before it reaches the diagnostics at the end of NounPhrase. Next we should try some diagnostics in the middle of NounPhrase. We insert diagnostics after the end of the search for the motjuste, but program-execution does not get that far and instead the Exception-crash occurs. So the problem may lie within the search for motjuste. We insert a diagnostic just before the ELSE-clause in the motjuste-search, and the diagnostic gets executed many times during non-crash thought, but not at all during generation of the thought that eventuates in the Exception-crash.
At the deepest indentation of the motjuste-search, where the "audjuste" variable is loaded with a value, we insert a diagnostic message. We run the AI. Gobsmack! From deepest NounPhrase, we get three diagnostic messages just before the Exception-crash. We notice that there is a "verblock" value of "423" as reported by the diagnostics just before the crash, so we search through the source code for the the number "423". Its only, unique appearance is at time-point t=554 in the EnBoot sequence, where "423" is assigned to the "tqv" (time-quod-vide) variable. But there is no t=423 time-point. It is interstitial, between the words "WHEN" and "WHERE" in the English bootstrap. Let us look at the source code of the JavaScript AI and see what is there. In the 14apr13A version of the JavaScript AI, at t=554 the value of "557" is assigned to "tqv", so "423" is wrong in the MindForth AI. In fact, two of the values in the Forth AI seem to have been erroneously held over from the older Forthminds before the EnBoot concepts received new concept-numbers. Let us change the pertinent section of the MindForth EnBoot to conform to the values in the JavaScript AI EnBoot() module. Hmm, when we correct the EnBoot segment, we get different output, but we still incur the same Exception-crash.
Now after massive diagnostics we find that the Exception-crash is occurring during the search for "motjuste" when the Index is at a value of "542", a point in time. Let us see what is at the t=542 time-point. We do see a t=552 error where "1" is used instead of "!" for storing a value. Let us fix that mistake.
As we correct various legacy errors from older versions of MindForth, the Exception-crash finally moves out of the time series of the EnBoot sequence and occurs once at t=615 in the time-span beyond EnBoot. Since our diagnostic message shows that the Index "I" has a value of "615" when the program crashes, MindForth must be traversing a loop at the t=615 time of the crash.
Thurs.24.JUL.2014 -- Solution found for defective search loopSince our Exception was crashing the AI when NounPhrase was already supposed to have found a noun or a pronoun, we decided to try inserting an "ELSE LEAVE" statement just before the Forthword "THEN" ending the search-loop. It worked. The AI stopped crashing and began to think interminably. However, our Acer netbook seems to run at a high speed, and so we may need to increase some "rsvp" values at places in the program.
Table of Contents (TOC)
