I know, I said tuesday or wednesday but it actually happened today, an update of the source code in the git repo.
I got some feedback already about a couple of minor glitches to fix, and the updated I pushed today has some of them already, there's no changelog neither versions yet, it is all 'trunk', sorry for that as I'll work it out in the coming days.
However, I managed to squeeze a nice small addition, you can now have a live view when murphy does it's stuff, here's the shot:
So, in the top-right corner there's a small preview window which constantly updates with what is happening in the virtual machine, useful for debugging / troubleshooting mostly. I'd like in the near future to also integrate it with the other functionality, meaning when you request a machine in a specific state you could see it working it's way to it in the 'Live' window. Probably even taking control of it right from the browser without the need to launch an external client, is not much to do as I have all the building blocks spread around.
The live view also introduced 2 nice things: requirejs (oh boy, how messy javascript can be...) and a small windowing library for html-javascript, it is something I've been poking around some time ago, while html is great for some things it sucks for others so it helps me a lot to have it here. Yez, you can resize, move the window around, close it and so.
Before I forget, the live preview is disabled by default until it has enough testing, but you can easily turn it on with a parameter in the base_extractor.py
Where are we heading nowadays then? well, first I'd like to get some feedback on the disk / network / registry capturing feature and more particularly how to show the information better, it is quite crude and raw at the moment.
Then? ah, start harnessing the possibilities of that information, meaning capture what happen when the network get's cut and the application tries to use it, sounds simple, but hey, if I cut the network then murphy stops receiving the images and sending the commands! so, it is not so trivial to do and may require a few attempts at it.
Then? arggggg, need to pay back code debt, fix some of the old code which is in bad shape, but that's an ongoing thing in background anyway. I will start converting things as to use requirejs on the javascript side and the inclussion of the pebble library.
Speaking of which, I'll explain a bit better what I *tried* to say in the last post:
>>I wonder if it could be simplified as much as to not to even have to use the get(), that'd be awesome.
What I mean is, that the following code:
@process()
def do_job(foo, bar=0):
return foo + bar
t = do_job(x, y)
returns a task object, so you must do then t.get()
However, with python is possible to return a proxy object, which in fact can do the get() call for you, to better picture what i'm talking about imagine the following case:
@process()
def calc_a(foo, bar=0):
return foo + bar
@process()
def calc_b(foo, bar=0):
...
@process()
def calc_c(foo, bar=0):
...
@process()
def calc_d(foo, bar=0):
...
a = calc_a(x, z)
b = calc_b(x, z)
c = calc_c(x, z)
d = calc_d(x, z)
result = (a * b)
if result > pp:
result += (c * d)
else:
result -= (d / c)
If calc_X returns a proxy object, the get is performed automatically on first use, and the synchronization is handled automatically for you 'in the background', otherwise the code would look like:
@process()
def calc_a(foo, bar=0):
return foo + bar
@process()
def calc_b(foo, bar=0):
...
@process()
def calc_c(foo, bar=0):
...
@process()
def calc_d(foo, bar=0):
...
a = calc_a(x, z)
b = calc_b(x, z)
c = calc_c(x, z)
d = calc_d(x, z)
result = (a.get() * b.get())
if result > pp:
result += (c.get() * d.get())
else:
result -= (d.get() / c.get())
I find it interesting because nowadays things tend to go into the closure's way, which IMHO are more confusing for this type of cases, the same code with closures 'a la javascript' or dart is indeed longer and a bit more obfuscated.
We did brainstorm further with Matteo and got some other interesting ideas that could be tried, imagine for example the decorator:
@parallel()
def calc_a(foo, bar=0):
return foo + bar
The 'parallel' implementation could execute it threaded, or as a separate process or even as a remote process on another machine, of course it is not quite trivial to do neither to know beforehand what would be most efficient but there's the challenge! and an interesting one, you could give hints or preferences about where to execute, or collect timming information on the fly and use it later... quite interesting...
But then again, the post is getting quite long and I already started to babble.
-Mat
