[Tinyos-devel] Re: Python SDK

[Geoffrey Mainland]

The current code we use is at:

http://senseless.eecs.harvard.edu/repos/fiji/tools/python/tinyos-1.x/

Only minor changes are supposedly needed for TinyOS 2.x
compatibility. Matt has an undergrad who made the changes, but they
never made it back into a publicly available tree. I've been meaning to
update the code myself but have too many other things on my plate right
now. It will be done by the end of the summer.

I purposely stayed away from using twisted or even threads of any sort,
although the current interface could easily be wrapped in a thread or be
wrapped by a Twisted component. I also tried to simplify the interfaces
relative to the Java version.

Geoff

On Tue, Jul 03, 2007 at 06:17:28PM -0400, Matt Welsh wrote:
> Vlado, we likely don't. I was going for the path of least resistance  
> here. Our code mostly mirrors the Java libraries for those folks used  
> to working with the Java SDK. Clearly one could imagine all kinds of  
> improvements but I wonder if it would be helpful to other folks to  
> get our basic stuff in there soon, and then you guys could improve on  
> it??
> 
> 
> On Jul 3, 2007, at 6:01 PM, Vlado Handziski wrote:
> 
> >Looking at the code, it looks like we can modify MIG to directly  
> >generate nescDecls.TosMsg instead of the current mirroring of the  
> >java approach. Why do we need both Message and TosMsg in TOSSIM?
> >
> >Vlado
> >
> >On 7/3/07, Vlado Handziski <handzisk at tkn.tu-berlin.de> wrote: On  
> >7/3/07, Philip Levis < pal at cs.stanford.edu> wrote:
> >On Jul 3, 2007, at 2:33 PM, Vlado Handziski wrote:
> >
> >> If we aim for 2.1, we should first fix MIG because the code that is
> >> currently generated is sometimes "unpythonic". Better support for
> >> message encapsulation/decapsulation is also very important. I am
> >> not sure how far these issues are addressed in the code from Matt,
> >> but they were the main reason why we did not submit to the core our
> >> serial forwarder implementation based on twisted python. We use
> >> internal workarounds for the above problems, and pushing them into
> >> the core would have required rewriting major parts of the TOSSIM
> >> python support.
> >
> >Can you be more specific?
> >
> >Well, things like:
> >
> >    #
> >    # Read the array 'data' as a String
> >    #
> >    def getString_data(self):
> >        carr = "";
> >        for i in range(0, 4000):
> >            if self.getElement_data (i) == chr(0):
> >                break
> >            carr += self.getElement_data(i)
> >        return carr
> >
> >in MIG output;
> >
> >missing proper getters and setters in Message for self.data, etc.
> >
> >
> >> Another "nice to have" item would be to update the rpc and the nesc
> >> modules from Kamin to handle the platform independent message
> >> structures. This will give us a well rounded, powerful SDK.
> >
> >Agreed. But let's not make this a blocking item for progress on more
> >contained (and pressing) issues.
> >
> >
> >That's why I said that this is "nice to have" :)
> >
> >Vlado