Getting Started

[jhe...@googlemail.com]

Hi there, 

I have been trying to follow the setup guide from last june but i am having difficulties.

I resorted to trying to use the command line interface, but maven is complaining about not being able to fine something: 

  eu.semsorgrid4env.service.sds:sds-wsdl:jar:0.1.1

from the specified remote repositories:

  central (http://repo1.maven.org/maven2),

  ssg4env.internal (http://ssg4env.techideas.net:8180/archiva/repository/internal)

Any help is appreciated.

[alan stokes]

Hello jhebus

We're aware of the problem, and are currently working on a solution for it.

We would like to know a bit about how you plan to use SNEE. This will help us in the future to provide useful feedback.

thanks

Alan Stokes

--
You received this message because you are subscribed to the Google Groups "SNEE user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snee-user+...@googlegroups.com.
To post to this group, send email to snee...@googlegroups.com.
Visit this group at http://groups.google.com/group/snee-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jhe...@googlemail.com]

Hi Alan, 

Any idea when this may be fixed.

I am working on VMs in sensors, specifically as light as possible migration and adaptability.

I was wondering how easy it would be to replace your nesC generation phase with a generation for my language and OS for sensors. In theory it should be able to remove the multiple images that you have on a mote just now, freeing up space, and reducing the amount of info (and power) which is used to send updates. So i wanted to get it working to see what it all looks like and how easy the replacement would be.

Would this be something that you are interested in?

[alan stokes]

Hi jhebus,

ive got to get the old developer whos module thats broken to get aroudn to fixing it, and hes currently ill at home and on a different project compeltely now.

But from the sounds of things, you can use my workaround for the bug, as the module is to do with querying out of network data streams, just commenting out the module in the snee.pom sorts it (kinda like dismembering a limb off snee, but does the job).

When you say migration and adaptability, you peek my interest, as im a phd student whos working on making snee more resilient to failures of such, and therefore the word adaptability rings many bells with me.

I do think we might have some stuff to chat about first though. As the code generator that turns our Query execution plan (QEP) into nesc code is just a module that you could replace easily enough to create your own binaries for your language and os.

Now the bit youve got me worried about is this "multiple images that you have on a mote just now". we don't have multiple query images on a mote. The different images go on different motes, and together they execute the query.

I recommend you read one of our papers which explain the SNEE QEP structure, which ive listed below:

http://link.springer.com/article/10.1007%2Fs10619-010-7074-3
http://dl.acm.org/citation.cfm?doid=2258056.2258066

thanks
Alan

[jhe...@googlemail.com]

Hi, 

Will give it a go.

Glad that you interest is peaked.

What i mean by multiple images it that as i understand it from your papers there are always 3 images:

1 to collect the network info

1 to handle the over the air programming, and

1 to do the query.

Is this wrong?

[jhe...@googlemail.com]

On Tuesday, 5 February 2013 14:58:04 UTC, alan stokes wrote:

Also, 

Exactly which file is that? Is there a specific snee.pom, or is that one of the pom.xml files? New to maven.

[Paul Harvey]

Hey dude, 

I am clearly not getting this right because if i remove the "<!--<module>data-source</module>-->" then i get all sort of dependency errors. As i try and make them go away i eventually get java "foo not found" errors.

Is there any chance that i could grab a zipped copy of what you have that seems to work, or am i missing something in asking for that?

Paul

[Alvaro A A Fernandes]

Paul,

I'm one of the academics behind SNEE. I'm pitching in to say that since your work (correct me if I'm wrong) is done in the context of Al Dearle's and Joe Sventek's research, it may be a good idea for a few of us to have something like a Skype chat in order that we can all understand how best to help you.

As you probably know, SNEE started to be designed and developed in an EPSRC project led by Joe and in which Al was involved too. However, after that, SNEE went into different directions in the wake of funding by the EU that gave priority to out-of-network execution, so the code base is a bit complex as a result.

On the one hand, it's fair enough that the code is all that counts. On the other hand, if we can understand better the research context, some assumptions made, the techniques that were used to build SNEE in the circumstance that applied at the time, then perhaps it's easier for Alan Stokes and perhaps ex-SNEE people to pitch in and help you better.

Does this seems a sensible suggestion? If so, would you recommend that we read one or more of your publications in preparation for the chat? If so, are they here

http://www.paul-harvey.org/publications.html

?

Alvaro

[alan stokes]

Hi Alvaro,

Ive been having a chat with Paul over google chat this morning, mainly to see if we can get him to be able to run the code so that he can look at how the code works and therefore give him a better grasp of what/if he wants to use our code base as a base line for his VM work.

If you want, i can invite you and alasdair to the chat (kinda just happened when i arrived back last night and this morning).

Ive adtached the dialog to the email so that if you dont, we're still up to date with discussions.

Ive basically said we should orgnaise the skype chat to get a better handle for us all, and started him rolling on getting a developer setup of the SNEE trunk code base. As working SNEE from the command line is a area i wouldnt want to travel to, it hurt enough trying to get condors jar to work for commandline.

thanks

Alan

[Paul Harvey]

Hi Alvaro and Alan, 

Thanks for getting back to me, and this definitely sounds like a sensible suggestion. My work is currently being done in the context of Insense and Joe is my supervisor. He was the one who pointed me towards your work. We were actually going to get in touch to ask about what you were doing with Insense at the time. I found some in-network queries that were being written in Insense and was wondering if these were automated or hand crafted. 

I suggest that i get the normal SNEE build environment up and running, have a look at what is going on and get back in touch to sort out a skype meeting.

This paper describes where Insense got to and the OS for sensor motes that i wrote to match the language requirements in Insense: http://paul-harvey.org/papers/sensornets2012.pdf.

Thanks very much, 

Paul 

[Alvaro A A Fernandes]

Hi Paul,

I've now read your SENSORNETS 2012 paper. It's quite interesting and exciting to see what you have achieved. Congratulations!

The paper, along with the chat you had with Alan, has clarified for me what I believe to be the main interest that drew your attention to SNEE, viz., the over-the-air-programming (OTAP_ capability, if I understand correctly.

The bad news is that we (the currently-active SNEE crowd) know next to nothing about the OTAP capability that was demonstrated in our BNCOD 20111 demo paper.

The story behind that capability is that in the EU project that funded SNEE for three years (after the initial collaboration with Joe and Al, among others), we were obliged to demonstrate it. Since OTAP wasn't (and isn't) anywhere close to the core of our interests and expertise, we essentially subcontracted the development of OTAP code by hiring for a short period a former PhD student here at Manchester, Robert Taylor, that had significant expertise in this area. However, we (i.e., the rest of the team) essentially treated the task and its outcomes as a black box, i.e., we didn't delve into the design and construction of it and therefore have little legacy that we could share with you.

In order to add some technical substance, recall that Deluge (i.e., the standard OTAP software from the TinyOS activity) distributes the same image to all the motes. One of the distinctive characteristics of SNEE is that it generates mote-specific images. So, Deluge was to restrictive for us to use. Robert Taylor adapted Deluge to serve our purposes. Thus, roughly speaking, in motes that are participating in the evaluation of a SNEE query, there are, conceptually, four binary-level components (the way they get realized as executable bytes may blur the conceptual boundaries, but I don't quite know the details): a controller, a metadata collector (this essentially allows us to pass back to the compiler what is the current connectivity graph over the available deployed motes), a code installer, and the query evaluation code. The third element in that list is probably the most interesting to you and the least interesting to us. :)

Depending on how this is done at the compilation level, there may be in some branch of the SNEE code base the nesC code corresponding to Robert Taylor's adaptation of Deluge. If so, this, I suggest, is probably the focus of your interests. As I said, the bad news is that we cannot support you: we know very little about it, it's far from our centre of gravity.

The broader points that were touched upon since you made contact, viz., the long-standing ambition of compiling SNEE queries into Insense or, now, InceOS, seems to me a very different (and to us much more interesting) topic. You're right that while the DIAS-MC project was active there were interactions between Ixent Galpin and Jon Lewis to try and code (by hand, in Insense) some SNEE-generated query execution plans, but, as you probably know, the issue of too large a memory footprint when Insense code was passed through Contiki precluded any advances in that respect.

Anyway, this long email is to suggest that you and Joe ponder whether there's much to be gained from a telecon in view of the fact that we have little to share with you about OTAP (other than, of course, the code written by Robert). If you two feel it's useful to chat, it will be a great pleasure. I just didn't want it to be based on a misunderstanding of what we're in position to offer in terms of help.

So, let us know what you and Joe think.

Alvaro