GitLab

"programs" command.

expected_exit_code) that get used by the newer program agent.  Add
virt_user_environment table that stores user config data for an
experiment.

vmc-client.c .

Hope to do this someday soon...

node) brings up a context menu that allows you to 1) Cancel the
current drag operation for that robot, 2) bring up the Emulab shownode
page in another window, and 3) set the orientation for the robot using
a popup dialog input box. This allowed me to clean up some of the
table handling code, and fix a glitch whereby a value left inside a
cell being edited caused the a cancel drag operation to immediately
start a new one.

into a single larger one.

create "delta" images based on the hash signatures that can be computed
by imagehash for an image.

To be used as a backup for NFS.

* Add nodeinfo backend page for the tracker applet to query for info about
  the nodes, including what type, what size, fixed/mobile, allocated etc.
  This is so we can draw the dots in the right scale, and make sure that
  fixed motes cannot be dragged around in the applet.

* Clean up a bunch of hardwired constants, mostly related to the size
  of the dots, and the font size (which determines where labels get
  drawn.

* And then I noticed the oddity resulting from having a robot that is 10.5
  inches long, but sweeps a diameter of 14 inches. The dot we draw is in
  scale (10.5in), but when I changed it to draw a 14in scale dot, that
  looked all wrong. So, there are actually two sizes now; the size of
  the robot, and the radius of the circle it sweeps (which is critical
  for determining obstacle avoidance). Still, this is confusing cause the
  user will place a robot near an obstacle (not overlapping) but will be
  told there is overlap cause the bubble around the robot is bigger then
  the dot. Not sure what to do about that. I could draw a large bubble
  around the robots but that is going to increase the clutter quite a bit.

current robot location (or its destination if the other robot is
moving or being dragged to a new location).

Oh, I should mention that to make the calculation easier, I am
treating robots as rectangles not circles. This is not ideal, but I
was not sure how to calculate overlap of two circles in a reasonably
efficient manner. I'm sure a high school student can tell me though.

browser.

fully contained within at least one camera (not the entire robot).

magical (atleast on OS X it is).

prepending zeros on times like "11:8:59".  Change the "baseurl"
parameter to "floorurl", since "baseurl" seems magical (atleast on OS
X it is).

bunch of "static" declarations cause they were wrong to use in the first
place (now that I understand what static means in a class definition).

burgeoning Java Applet skills to to write a little applet to decode
the motion jpeg stream that the webcams spit out. Not exactly
efficient, but at least it works everyplace I tried, even with
Internet Explorer.

For the web page, the default view is still static, with an option
near the top to use the applet version of the page. The nice thing is
that when you leave the page (go someplace else) the data stream
actually stops (cause the applet is stopped).

Just click on the table cell of the destination orientation, and give it
a new value.

pretty good at this point, although still not able to set just the
orientation without moving x,y. Will work on that next.

append ".exe" in favor of the --enable-windowsclient option.

ability to move multiple robots around. Still needs testing, but
want to get this off my laptop just in case windows decides to do
something stupid ...

setdest events for robots. See www/robotrack/setdest.php3