Specifications

Don’t Define Functions Twice
In SNAPpy (as in Python), defining a function that already exists counts as a re-definition of that
function.
Other script code, that used to invoke the old function, will now be invoking the replacement function
instead.
Using meaningful function names will help alleviate this.
There is limited dynamic memory in SNAPpy
Functions that manipulate strings (concatenation, slicing, subscripting, chr()) all pull from a small pool
of dynamic (reusable) string buffers.
NOTE – this is different from prior versions, which only had a single fixed buffer for each type of
string operation.
You still do not have unlimited string space, and can run out if you try to keep too many strings.
Use the Supported Form of Import
In SNAPpy scripts you should use the form:
from moduleName import *
from synapse.moduleName import *
Remember Portal Speaks Python Too
SNAPpy scripts are a very powerful tool, but the SNAPpy language is a modified subset of full-blown
Python.
In some cases, you may be able to take advantage of Portal’s more powerful capabilities, by having
SNAPpy scripts (running on remote nodes) invoke routines contained within Portal scripts.
This applies not only to the scripting language differences, but also to the additional hardware a
desktop platform adds.
As an example, even though a node has no graphics display, it can still generate a plot of link quality
over time, by using a code snippet like the following:
rpc("\x00\x00\x01", "plotlq", localAddr(), getLq())
For this to do anything useful, Portal must also have loaded a script containing the following
definition:
def plotlq(who, lq):
logData(who,lq,256)
The node will report the data, and Portal will plot the data.
Page 90 of 202 SNAP Reference Manual Document Number 600-0007K