[Tinyos Core WG] Re: Python scripts

[Philip Levis]

On May 17, 2007, at 3:16 PM, David Gay wrote:

> On 5/17/07, Razvan Musaloiu-E. <razvanm at cs.jhu.edu> wrote:
>> Hi!
>>
>> On Thu, 17 May 2007, Philip Levis wrote:
>>
>> > On May 17, 2007, at 1:49 PM, Razvan Musaloiu-E. wrote:
>> >
>> >> Hi!
>> >>
>> >> One last question: where exactly in the tools/ should we put  
>> the Python
>> >> scripts?
>> >
>> > Hm. It might make more sense to put them in support/, since they  
>> interact
>> > with nesC code. Otherwise, if someone changes the Deluge code it  
>> might be
>> > hard to update the scripts.
>>
>> To make things more clear, here are a brief description of our  
>> scripts:
>> - deluge.py: this is used to perform the regular Deluge operations  
>> (ping,
>>    inject, reboot, etc)
>> - build-deluge-image.py is used to build a binary image from a
>>    tox_image.xml.
>> - tinyos.py is a library that contains two class: Serial and
>>    GenericPacket. Serial deals with sending/receiving and
>>    decoding/encoding of the serial messages. GenericPacket is used  
>> to e
>>    marshal/unmarshal the data from packets.
>
> Hmm, some comments about tools vs support:
>
> - tools is the command line tools needed to use (compile, install,
> debug, etc) TinyOS code
>  It's contents are distributed as the tinyos-tools rpm, and should
> probably not be (too) dependent on the current state of the rest of
> the TinyOS tree
>  Also, when possible, we have all the tool names start with tos- to
> reduce the level of confusion (we don't do this for tools from an
> external source, though, e.g., uisp)
>
> - support is the stuff we want to distribute with the rest of the
> TinyOS code, but that isn't TinyOS code. Currently that's basically
> the make system and libraries to support PC-side activities in various
> languages (C, Java, etc)
>  FWIW, we recently started putting PC-side applications that support
> a particular TinyOS application with the TinyOS application (i.e., in
> apps)
>
> Currently, all executables  (scripts and binaries) are in
> tinyos-tools. Life is simpler when the main tinyos package does not
> contain executables - it makes it easier to use CVS instead of
> distributions, makes the tinyos rpm relocatable, forces us to think
> before breaking the existing tools ;-)
>
> So from your list:
> - tinyos.py sounds like something which should be living in
> support/python (it sounds useful for any TinyOS programmer who wants
> to interact with motes using python)
> - if deluge.py and build-deluge-image.py are command line tools:
>  - they should start with tos- (and lose the .py suffix - the user
> doesn't care that they're written in python)
>  - they should live in the tools directory and be distributed with
> the tools package
>
> I guess they're may be an issue with tinyos.py being needed by
> deluge.py and build-deluge-image.py? I'd actually suggest just having
> a "private" copy of tinyos.py that lives somewhere in the tinyos-tools
> package.

Hm. It seems these tools are halfway between the two. This gets to a  
bigger issue, that often we want some things like tinyos-tools inside  
the tinyos code. E.g., I added tos-mviz to tools/ but would really  
prefer it to be in support. Moving people away from java  
net.tinyos.blah blah blah would be great.

Here's my suggestion. We should create a support/bin directory for  
command line tools that interact with the support code. Scripts like  
tos-mviz (which basically just invokes java net.tinyos.mviz) as well  
as tos-deluge could move in there. The RPM puts them in the right  
place when you install it.

Phil