This meeting will focus on the upcoming need to demonstrate the functionality needed by the visualization software. To this end, I describe below a simple use case, itemized (I hope) in enough detail to generate a discussion of the remaining development needs.
Calculate (on the server) the average pixel value in a region specified by the client.
Client determines the region parameters.
For now, only rectangular regions, specified by the (x,y) of the upper left and lower right corners.
Three ways to determine the parameters (not all are needed for the demo).
From the FF toolbox. Requires client/FF communications ( this has been demonstrated).
From a list of named regions.
By hand on the command line.
Client assembles a command (plain tex?) to send to the server.
Command format “av_pixel “box name” “viewer name” x1 y1 x2 y2”
“box name” is the name of the box (created with the “create_box” command) to display the result
"viewer name" is the name of the FF viewer window to use (in case there are more than one).
Client gives the command to FF to send to the server.
What FF function does it call? What are the parameters?
FF sends the command to the server. Is this transparent to the user?
Server receives the command from FF.
What FF function does it call? What are the parameters?
Must the server be listening? Is an interrupt generated?
The server parses the command and executes the desired function.
How does it get the pixel data?
Does the function require any DM (or other) libraries?
Server gives the result to FF to send to the client.
What FF function does it call? What are the parameters?
What data formats are allowed?
Client receives the result from FF.
What FF function does it call? What are the parameters?
Hoe does the client know what command generated the the response?
@dyue2 This might because sub-modules are actually linked to a particular commit and we did not include them when we pushed changes on GitHub. I’ve updated their links to the latest commit so that git pull now should checkout the latest version. I’m looking into ways to keep sub-modules always on master branch.
This might because sub-modules are actually linked to a particular commit and we did not include them when we pushed changes on GitHub.
I don’t think this is a complete explanation, because when I did a fresh clone --git recursive (yesterday) I did get the up to date files in the subprojects.
I think the simplest way is to change to the directory and update each with a git pull
This did not work directly, for example:
cd frontend
git pull
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
Maybe if I was a git expert I would know what to do about this, but I do not.
I looked up online and there is command git submodule update and it might require git 1.8.2.
I have git 2.5.0, and indeed that worked!
tonyj@Rivendell:~/projects/lsst/vis/camera-firefly-save$ git submodule update
Submodule path ‘backend’: checked out '380457a2a37dfd296de9af127f3c3d467b73842a’
Submodule path ‘frontend’: checked out ‘f80a053d8a474d30d051f336ccc4790014b12fdd’
Thanks – it might be useful to put that command in the README.md
I did a fresh checkout yesterday and got the older version files though. Maybe you did the fresh clone after I updated the links.
I also reproduced the error that git pull in each sub-module directory is not working. I think that’s because by default sub-modules are identified by a unique commit instead of a particular branch. When we checkout the code from upper directory (“lsst_firefly”) without specifying branch for sub-modules, they become detached HEAD. So inside each sub-module directory you need to:
git checkout master && git pull
it should switch to master branch and update the code.
Anyway, git submodule update seems the best solution.