Bugs

At this very moment the code has not been tested by any person except myself. I managed to run succesfully each of the demonstration programs that come with the original program. When running these program I discovered quite some home made bugs which I fixed. But since programmers are bad testers I will not make any claims here.

So far I have test the programs under Linux kernel version 2.2  I have succesfully run the program on 2 processor machines and a cluster of workstations. I hope to provide some test result on this page later.
 

Identifying bugs

In order to ease the debugging process information will be provided by the program. Althought this will indeed introduce some overhead I believe this to be worth it. Do not expect too much though, what you will get is an extremely short message. This message mentions the name function and (if I have been consistent) the operation in that function that failed.

In pratice this means that all the PVM related functions will provide a brief description upon failure. This should help you identify problems whenever they would be related to PVM or the kernel itself.

I include some sanity checks as well. The most heavy onces are left out if you compile your program without the debugging defines. So if you want to find the bug yourself you should start by uncommenting the defines in the GNUmakefile.

When reporting a bug it might be interesting to include some part of your PVM log file. This is especially true if you compiled the kernel with the debugging defines.

Bug list

• April 19th, 2002
  Included bugfix sent by Olivier Nicolas: "A couple of mistakes were introduced in the randomizer code (kernel/random.c) during it's translation from fortran to C.It causes the program to crash with particular values of the seed (specially high values)."
• August 29th, 2001
  The tree generation using the grow method was virtually identical to the full tree method. This did not only matter for tree generation but also for the mutation operator. Strong typing is more flexible now! You can leave out functions or terminals if you do not really need them. On the down side it can be that you have to consider tree generation more carefully now. Maybe you can't make full trees when you leave out some functions for instance.
• May 30th,
  One more bug, this one was concerning the exchange of individuals. Things got a little confuse (read it crashed) when there were more exchanges then subpopulations on a node. I also added a silly "warp" thing in the output, it give roughly the speedup that is achieved. You also get more output while using the kernel in asynchronous mode, not dots anymore. As it happens the output is quite similar to the one you get in synchronous mode ;-)
• May 15th,
  Strong typing related bugs were remove (it was friday come on :-) My "It seems to work just fine" was true because there was only one type. But now it is also true if you use several types, now I can work.
  You need to define at least one terminal and one function for each type! If not you get some nice core dumps.
• May 12th,
  Althought the kernel still needs som cleaning (it seems I do not deallocate everything) I will not got into that now. Making the kernel strongly typed ha been my occupation of the day. If you are looking for a typeless kernel (or you are using the original Lil-gp kernel) do not worry you can still run you problems with it. You need to change only a few lines in your code!! You just use the strongly typed kernel with only one type that's all.
  For people who would like to know more about a strongly typed Lil-gp kernel there already is the kernel patched by Sean Luke (seanl@cs.umd.edu). His page is " Sean's Patched lil-gp Kernel". I merged parts of his code into the parallel kernel. Things look fine now, why not try it out.
• May 11th, reporting corrected
  The kernel used to produce some incorrect reports (at least the .stt file). The statistics collected there were correct for each generation but not for the global statistics. This should be solved now. You won't see any difference on screen but the timing information (you know these "( 0s 0s 0s 0s // parallel)") are really corresponding to the generation you see on screen. (Screenshot)