Why PAWN ?

[Xasher]

I don’t understand why UGobe chose to use Pawn language scripting to program Pleo? Pawn doesn’t have any Interrupt request capabilities, therefore the program needs to constantly monitor the inputs from the sensors within the code. This requires the code to be much larger and it slows the processing down quite a bit. It seems like a waste of the small amount of memory Pleo’s IC chips have.

[PleoPet]

I'll let the UGOBE folks explain/defend their decision.

FWIW: The sensor script does have an 'on_sensor' function that is called in an interrupt-like way when the sensor values change. You handle everything in a big switch/case statement (relatively efficient/small program code)
There is also a special case 'on_property' for property changes. It is not a general feature. Once the PDK is released, and people start writing their own Pawn programs, I suspect there will be additional specific feature requests for UGOBE (eg: adding 'on_' callbacks to all modules?)

[Xasher]

Now that I’ve read up on Pawn I believe I understand why Ugobe chose to use Pawn. If I were to guess I would have to say they didn’t use Pawn for the base program in Pleo but are having third party programmers use Pawn because of it’s stability. From what I understand Pawn works as an external programming language and no matter what the user programs there is little chance that they can crash the Pleo’s main program. This allow 3rd party programmers to experiment without the fear of crashing the Pleo’s main program.
Pawn also has the ability to allow users to substitute files just by naming files the same as the base program but changing the designator. Example: most files used by Pleo probably end with .inc, if an end user wants pleo to utilize his file instead of the base file he could name his file the same and use the .p or .pawn designator and Pawn will utilize that file instead of the old one. This is why you can substitute sound files on your SD card and Pleo will use them instead of the original sound files.
Pawn programming language is similar to C so most programmers with any experience with C or Basic would be able to pick it up with little time learning the language. The only issue I can see really with Pawn is it replaces files easily but will it accept modules of code to override the main program ? It looks to me that if we are replacing sound files Pawn is great but how will we go about reprogramming Pleo’s movement commands. Have you made all his movements into Files that we can substitute similar to the sound files ? If this is the case, since SD file transfer is very slow and Pawn as a language is also will there be a limit to the size and scope of the movement commands we create ? My guess is the programs will run very slow, especially if the programs third party developers will write will all have to constantly be checked by the main program substitute the file on the SD card download the file and then run by Pleo.
On the upside if I am correct about my assumption above, Ugobe really only needs to release the names of the files they are using and tell us what each one does, to get the third party programmers up and running.

[alex_r]

Pawn also has the ability to allow users to substitute files just by naming files the same as the base program but changing the designator. Example: most files used by Pleo probably end with .inc, if an end user wants pleo to utilize his file instead of the base file he could name his file the same and use the .p or .pawn designator and Pawn will utilize that file instead of the old one. This is why you can substitute sound files on your SD card and Pleo will use them instead of the original sound files.

That isn't what actually happens. Whatever source files (.P, .INC or whatever) you originally have, they all got compiled together into an AMX module. Then the AMX plus any additional resources (sounds, movements) got linked together into a single .URF file. Then you copy the URF into an SD card and stuck that up Pleo's... card slot. The thing with replacing sound files is about placing on the same SD a sound file with the same name as one of the resources in the .URF. When this happens, some runtime function (probably called something like play_sound("sound_file_name")) would supposedly fetch the outside resource with the same name instead of the one in the .URF.

By the time the thing is running inside Pleo, there is no .P, .INC or any other source files in there, they are all left behind on your development PC.

[PleoPet]

> The only issue I can see really with Pawn is it replaces files easily but will it accept modules of code to override the main program ?
Yes, this works quite easily, but as mentioned, only at the .AMX level.
For example if you create your own main.amx and sensors.amx and copy them to the root of the SD card, it will run that program, but get the sound/motion resources from the PLEO.URF. That's how 'YAPT' works with pre-existing personalities, as describe here: http://www.aibohack.com/pleo/yapt2.htm

>...Have you made all his movements into Files that we can substitute similar to the sound files ?...
Yes, the motion files are binary resources as well. They can either be part of the bigger PLEO.URF, or separate UMF files on the SD card.
For a small number of sounds or motions, placing them in separate files works well ("shadowing"). For replacing many of them, you are better off rebuilding the larger PLEO.URF file.

>Ugobe really only needs to release the names of the files they are using and tell us what each one does, to get the third party programmers up and running.
The names can be found by dumping the PLEO.URF. That's enough for changing the sounds and motions.
Changing code is much more difficult. Even in the current personality, there are 43 different AMX modules (some are trivial), but they all talk to eachother. Without the source for the original, replacing one or two AMX modules is very dangerous
(NOTE: the "YAPT" approach works because it is replacing the entire personality)