[Tinyos-devel] Re: Python SDK

[Matt Welsh]

Thanks Geoff.

We have an updated version that works for tinyOS 2.x also (it is not  
in the tree below but I can get it in there easily, or email someone  
a tarball).

Matt

On Jul 3, 2007, at 6:22 PM, Geoffrey Mainland wrote:

> 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
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/ 
> tinyos-devel