1

Topic: The Python and the Dead Cow

I recently had to write some rather involved nWare python scripts, and I immediately ran into the problems that makes any serious scripting next to impossible using the built in editor.
However, I figured out it would be rather easy to 'simulate' running a python script the way it is run into nWare, but outside of nWare. Using a normal shell, editor and so on.

So, at the risk of beating a dead cow, I'll explain how I did it.
The idea is to prepends some python that sets up 'variables' that simulate the extensions defined by nWare. Typically, inputs/outputs/message and event.wait().
Once you have that, you can enter a set of input values yourself, in code, then run the script into the shell (cygwyn, linux, or whatever command line you fancy), and watch the outputs.
When you are happy with the logic, copy/paste your script (minus the simulator glue) back into nWare editor and test 'live'. It's surprisingly painless once it gets going, and you get the advantage of being able to choose your editor, and have proper error messages with line numbers (wheee!) etc. Oh and you can use the best debugger of them all : 'print' !

Here is the prefix I used. It's easily extensible to handle numerical values and so on..


import sys
import time

# this allows the script to do "event.wait(xxxx)"
class Event:
def wait(self,long):
  time.sleep(long/1000)
global event
event = Event()

# this simulates inputs, outputs and message.Extends to implement the other methods
class nWare:
def __init__(self, what,value):
  self.what = what
  self.value = value
def string_get(self):
  return str(self.value)
def string_set(self,value):
  self.value = str(value)      
  print ">>%s = %s" % (self.what, self.value)

# declares this particular script input and outputs. You can set whatever values you fancy.
global inputs, outputs, message
inputs = [ \
  nWare("inputs[0]", "reserved"), \
  nWare("inputs[1]","10.18.10.45|1|1|0|0|0"), \
  nWare("inputs[2]","10.10.0.44|1|0|0|0|0") \
];
outputs = [ \
  nWare("logger","logger"), \
  nWare("outputs[1]",""), \
  nWare("outputs[2]","") ];
message = nWare("message","")

# your own script starts here !

2

Re: The Python and the Dead Cow

Nicely done, I did the same after my first few painful NWare debugging sessions!

What version of Python should I do my scripting development on to ensure that the resulting scripts run ok on:-

NWare Emulator - Python 2.4 Reduced?

Conman - Python 2.4 Reduced?

Nion - Python 2.0 Reduced?

3

Re: The Python and the Dead Cow

This is a great idea, but it does not address the fact that the Python implementation on NION is not standard Python, but reduced feature subset. I have had many occasions when Python scripts work under in an emulated NION file, but will not work when deployed to hardware due to different libraries being available.

How can we know what is supported by the NION kernel and/or ConMan? And perhaps more importantly, can you make it so that the emulator truly emulates the hardware environment, and will not run scripts that will fail when deployed to hardware?

Thanks!

Thanks!

Dave

4

Re: The Python and the Dead Cow

draudio,
  I understand your issue about the emulation supporting more than the NION.  I'll add your suggestion of limiting python when the target is a NION to the feature request list.

  Anything supported in emulation works on ConMan.

5

Re: The Python and the Dead Cow

The underlying reason for this issue is that the python running on the nion /had/ to be severely trimmed down just to be able to fit on the nion hardware. When emulating, we would have to run with two different runtime versions of python, and that would be quite a spaghetti plate to maintain.

6

Re: The Python and the Dead Cow

I understand your constraints. Is there documentation of what is (or is not) available on the NION kernel? (So I can avoid bumping my head anymore...;o)

Thanks!

Thanks!

Dave