GitLab

the controller.

areas.

all the time. Turning on exclusions just extends the shading around
the object.  Also pay attention to new DB flag "no_exclusion" which
prevents the zone from ever being drawn, and is used to reduce visual
clutter by turning of the zone for some obstacles. Also remove the
blue border around the zones, again to reduce visual clutter.

in the right size. Wow, we could probably even generate this image on
the fly, except that it has that nice little directional legend that Tim
added, and I don't want to mess with that right now!

Note that the new floormap code will draw all the obstacles, even the
walls, so there is not need for anything in the base gif anymore.

can see other robot areas.

Use node_startloc table to figure out where robots are physically
located initially, instead of using location_info for current location
and initial.

	* tbsetup/ptopgen.in: When adding features for nodes attached to a
	building (e.g. robots), pull the building names from node_startloc
	instead of location_info.  This change lets the robots exist in
	two different areas.

	* tbsetup/ns2ir/parse-ns.in: Pull building names from
	node_startloc instead of location_info.

	* robots/primotion/garcia-pilot.cc: Turn off the fall sensors,
	since they have a tendency to go off for no good reason.

	* robots/primotion/pilotButtonCallback.cc: A short-click on the
	user-button now shuts the garcia down.

	* robots/primotion/pilotClient.cc,
	robots/primotion/wheelManager.hh,
	robots/primotion/wheelManager.cc: Set the wheel speed.

Pass camera local to world offsets through vmcd.

	* event/sched/rpc.cc: Add the camera fixed_x,fixed_y values to the
	emcd.config file.

	* robots/emc/emcd.c: Pickup the cameras fixed_x,fixed_y values
	from the config file.  Add supports for setting the speed of the
	robot.

	* robots/mtp/mtp.h, robots/mtp/mtp.c: Add support for setting
	speed in GOTO packets and constructing vmc-client config packets.

	* robots/mtp/mtp.x: Add a vmc-client config packet that contains
	the cameras origin in world coordinates.

	* robots/mtp/mtp_dump.c: Dump the min/max values for x and y,
	handy for figuring out the bounds of the camera.

	* robots/vmcd/visionTrack.c, robots/vmcd/visionTrack.h: Handle
	cameras that are overlapping on two axes.

	* robots/vmcd/vmc-client.c: Accept a vmc-client config packet that
	tells us where the camera is in world coordinates.  Add an
	orientation flag that specifies how the camera is oriented wrt to
	the world coordinate system.

	* robots/vmcd/vmcd.c: Send vmc-client config packets out.  Fix a
	bug that left unknown tracks in the previous frame, which could
	confuse the matching algorithm causing it to match unknown tracks
	instead of valid known tracks.

This is a workaround for the STL swap function. It has some surprising behaviour, so I wrote my own.

Quick fix. The assignment operator for SetIterator.h did not return a value. This didn't cause any known current errors, but g++ 3.4.1 noticed.

exclusion zone on a per-obstacle basis, and 2) show the tooltip.

The ports-install script neglects to copy the ulsshblahblah port into
the ports tree, causing mayhem and havoc at remote site.  Updated.

path, users run this by hand so they can interact with it (ie. type
a password).

- but this file isn't php!

one is not left in the browser. Generally this does not matter,
except that I often switch between users from the same browser.

another node.

remote-site target.

J. Mirkovic, S. Dietrich, D. Dittrich, and P. Reiher, "Internet Denial of
Service", Prentice Hall PTR (December 30, 2004), ISBN: 0131475738

grabswitchconfig, suitable for daily running from cron.

and stashes it in a local file.

the fixed point on the ground where the camera origin is in world
coordinates.

into the Wiki when clicking on the My Wiki's link. Works like this:

* The My Wiki's link points to new page, gotowiki.php3, on boss.

* The gotowiki page looks for a new cookie in the user's browser
  which holds a key (the usual random data run through md5).

* If the key does not exist, generate it and store it in the user
  browser (expires when browser is closed or emulab login times out).
  Also invoke backend script wikixlogin, which will send the key over
  to the wiki server (via ssh), which will write the key into a file
  named by the user account.

* The user's browser is redirected to the wiki server's login script
  (twiki/bin/newlogon), but instead of username and password, we send
  over username and key (as well as redurl= parameter which is the
  page on the wiki server to redirect to later).

* The new login script looks for this case, and opens the file named
  by the user and compares the key it gets with what is in the file.
  If they match, the user login succeeds and the browser is once again
  redirected, but this time to the page it wants on the wiki server.
  If the key does not match, the browser is redirected to the login
  page (so user can enter username password normally). The redurl
  parameter is passed along as well.

* Subsequent clicks on My Wiki's will not need to invoke the backend
  script, since the cookie will be in the browser.

logon script, so that we do not have to use stinky HTPP basic auth.

the interfaces table. This will be used to override the defaults that
newnode assigns using the node_types table, since for ElabinElab,
interface roles are actually picked however assign feels like it, not
according to any rules.

for the near future. Two big changes:

* Add WikiOnly accounts. An external user can register for an account on
  the wiki. Rather then use the registration stuff that comes with TWiki,
  redirect to new Emulab web page so we can manage all of the wiki accounts
  from one place. I modified the joinproject page to spit out a subset of
  the required fields so that its simple to get a wiki only account (just a
  few things to fill in).

  In keeping with current security practices, we still generate a
  verification email message to ensure the email address works. However,
  when the user completes the verification, the wiki account is created right
  away, rather then waiting for someone to approve it (since that would
  defeat the entire point of the wiki).

  Aside: I have not thought much about the conversion from a wiki-only
  account to a real account. That is going to happen, and it would be nice
  if that step did not require one of use to go in and hack the DB. Will
  cross that moat later.

  Aside: Rather beat up on the modify user info page too much, I continue
  to spit out the same form, but mark most of the fields as not required,
  and allow wiki-only people to not specify them.

* Both the joinproject and newproject pages sport a new WikiName field so
  that users can select their own WikiName. I added some JavaScript to
  both pages that generate a suitable wikiname from the FullName field, so
  that as soon as the user clicks out of the FullName, a default wikiname is
  inserted in the field.

  Both pages verify the wikinames by checking to make sure it is not
  already in use, and that it meets the WikiRules for WikiTopic names.
  (someone please shoot me if I continue to use WikiNotation).

wiki pages for projects and users on an existing testbed. This
assumes I can easily partition the actual twiki code into a
distribution that we can give people. I haven't really thought much
about that, but I assume its not too hard.

do not replicate the notes into 1200 files (and of course, so we
easily change the notes later).

Checked in so we can track their evolution and so you don't
have to rely on Mike to remember where he stashed them!