fluid-work IRC Logs-2012-09-10

[08:16:03 CDT(-0500)] <Justin_o> jhung, cindyli: I started putting the camera control server spec in the wiki. http://wiki.fluidproject.org/display/fluid/Proposed+Decapod+Camera+Control+Server+Architecture

[08:16:09 CDT(-0500)] <Justin_o> still needs thinking through though.

[08:16:29 CDT(-0500)] <cindyli> thanks, Justin_o

[08:20:04 CDT(-0500)] <jhung> great justin_o.

[08:20:37 CDT(-0500)] <jhung> I'm going to be interested in seeing what you guys come up with with respect to calibration.

[08:46:32 CDT(-0500)] <Justin_o> jhung: me too

[08:48:59 CDT(-0500)] <Justin_o> cindyli: here are some articles about post vs. put which i found interesting.

[08:49:00 CDT(-0500)] <Justin_o> http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/

[08:49:07 CDT(-0500)] <Justin_o> http://benramsey.com/blog/2009/11/post-vs-put/

[08:49:14 CDT(-0500)] <cindyli> ok, Justin_o

[08:49:14 CDT(-0500)] <Justin_o> http://blog.zacharyvoase.com/2009/07/03/http-post-put-diff/

[09:09:40 CDT(-0500)] <jhung> justin_o and cindyli, I am drafting an email to the IUPR folks outlining the timeline for Decapod 0.7. The intention to make sure they know when components are to be available for us to integrate.

[09:09:59 CDT(-0500)] <Justin_o> jhung: sounds like a great idea

[09:10:20 CDT(-0500)] <Justin_o> we should send something to the list as well with the planning page i guess

[09:10:35 CDT(-0500)] <jhung> yep. I'll do that after.

[09:10:48 CDT(-0500)] <Justin_o> jhung: thanks

[09:11:40 CDT(-0500)] <jhung> justin_o, cindyli, I will be editing the roadmap page to include IUPR components.

[09:12:19 CDT(-0500)] <Justin_o> jhung: makes sense.. i guess we only have some genpdf stuff there at the moment.. would be good to have more detail

[09:31:06 CDT(-0500)] <Justin_o> jhung: if we wanted to return information about the camera back.. e.g. through a GET request.. what sort of information do you think would be interesting

[09:31:35 CDT(-0500)] <Justin_o> jhung: here's an example from the gphoto2 documentation http://www.gphoto.org/doc/manual/using-gphoto2.html

[09:31:42 CDT(-0500)] <Justin_o> looks like we'll have to parse the output

[09:32:07 CDT(-0500)] <jhung> 1. Model

[09:32:34 CDT(-0500)] <jhung> 2. Megapixels / max resolution

[09:32:39 CDT(-0500)] <jhung> 3. Supported formats

[09:32:54 CDT(-0500)] <jhung> Not sure what else...

[09:33:36 CDT(-0500)] <jhung> Basically we'll want to check the models are matching for stereo. The megapixels must be at least 10MP, and JPEG, TIFF format (i.e. not RAW).

[09:34:41 CDT(-0500)] <Justin_o> jhung: here are the data structures which i guess hold all the possible info we could get http://www.gphoto.org/doc/api/annotated.html

[09:36:08 CDT(-0500)] <Justin_o> jhung: i wonder if we can actually set the capture format.. meaning jpeg vs raw, programatically

[09:43:32 CDT(-0500)] <jhung> justin_o: that's a good question. I don't know the answer.

[09:44:49 CDT(-0500)] <Justin_o> jhung: the gphoto docs don't seem very descriptive.. i think they are trying to be generic because the cameras area all different..

[09:50:09 CDT(-0500)] <jhung> justin_o: yes. I found often that what is written vs. what actually happens to be different. Best to test with our cameras and see.

[10:27:36 CDT(-0500)] <jhung> justin_o, cindyli: Originally we requested to have Stereo Calibration done by Sep 28, but we don't need it for UI development until Oct 15.

[10:28:00 CDT(-0500)] <jhung> I propose we shift it 1 week to give IUPR more time. This will not affect development work on our side.

[10:28:16 CDT(-0500)] <Justin_o> jhung: i'm fine with that

[10:32:12 CDT(-0500)] <jessm> fluid-everyone: standup

[10:32:23 CDT(-0500)] <jessm> must be TIFF – the daily standup reminder person is gone

[10:32:28 CDT(-0500)] <jhung>

[13:09:06 CDT(-0500)] <michelled> colinclark, jessm: let me know when you want to do more Floe planning

[13:09:24 CDT(-0500)] <colinclark> I think Jess was just scoring some chocolate

[13:09:28 CDT(-0500)] <colinclark> and then we're ready

[13:11:30 CDT(-0500)] <jessm> chocolate scored

[13:11:55 CDT(-0500)] <michelled>

[13:15:13 CDT(-0500)] <thealphanerd> colinclark: looks like you made some progress with flocking over the last week

[13:15:26 CDT(-0500)] <colinclark> yeah, i've been busy

[13:15:42 CDT(-0500)] <thealphanerd> did the syntax for the scheduler change at all?

[13:16:33 CDT(-0500)] <colinclark> It should be backwards compatible, but there are new features

[13:16:52 CDT(-0500)] <thealphanerd> and it appears it is now merged into the master

[13:16:56 CDT(-0500)] <colinclark> This example is telling: http://www.flockingjs.org/demos/interactive/html/playground.html

[13:17:04 CDT(-0500)] <colinclark> "Multiple Synths"

[13:17:06 CDT(-0500)] <thealphanerd> did you figure out those timing issues we were having with the tests

[13:17:15 CDT(-0500)] <colinclark> Take a look at line 24 and 28

[13:17:20 CDT(-0500)] <colinclark> yes, those are all passing

[13:18:12 CDT(-0500)] <colinclark> you can see them here: https://github.com/colinbdclark/Flocking/blob/master/tests/flocking/js/scheduler-tests.js

[13:18:29 CDT(-0500)] <colinclark> It's a tricky sort of test to write; I forget exactly what the details were

[14:03:23 CDT(-0500)] <jhung> Justin_o and cindyli, is it okay if I change DECA-310 to include all error cases for capture? I don't know if it makes sense to have jira for each case.

[14:03:49 CDT(-0500)] <Justin_o> jhung: sure

[14:13:49 CDT(-0500)] <jhung> justin_o, cindyli, I created DECA-324 which lists some error cases for capture. I have added it to the Deca0.7 planning doc.

[14:13:59 CDT(-0500)] <Justin_o> jhung: thanks

[14:15:54 CDT(-0500)] <jhung> justin_o, there may be more error cases we haven't thought of yet.

[14:17:00 CDT(-0500)] <Justin_o> jhung: okay.. fair warning

[14:34:01 CDT(-0500)] <Justin_o> jhung: cindyli and I are talking about the repo structure

[14:34:24 CDT(-0500)] <Justin_o> if want to make this really modular we would ideally have individual install scripts for each one and separate repos

[14:34:54 CDT(-0500)] <Justin_o> that would mean that instead of have a server and ui repo.. we would have export-server, capture-server, dewarp-server, and etc.

[14:34:57 CDT(-0500)] <Justin_o> what do you think of that

[14:35:09 CDT(-0500)] <Justin_o> this would also be the same for UI

[14:35:21 CDT(-0500)] <Justin_o> alternatively we can keep them all within the same server

[14:36:24 CDT(-0500)] <Justin_o> jhung: ^

[14:38:29 CDT(-0500)] <jhung> I see justin_o. This will make it easier to grab just the functionality you need. Makes sense.

[14:39:43 CDT(-0500)] <Justin_o> jhung: yes.. it would mean changing our current repo structure though.. and re-writing our install scripts

[14:39:58 CDT(-0500)] <jhung> hmmm.

[14:40:13 CDT(-0500)] <jhung> I think perhaps we can leave it the way it is for now. We will do it in the end if we have time.

[14:41:00 CDT(-0500)] <Justin_o> cindyli: do you think we could separate it later?

[14:41:19 CDT(-0500)] <cindyli> ya, should be able to

[14:42:07 CDT(-0500)] <Justin_o> jhung, cindyli: okay we can wait for later

[14:43:32 CDT(-0500)] <jhung> great justin_o.

[15:14:31 CDT(-0500)]

[15:15:50 CDT(-0500)] <Justin_o> the reason is that i get a dictionary of the query parameters from the url passed to the server. but these need to be translated into the list of arguments to be passed to the command line call

[15:16:06 CDT(-0500)] <Bosmon> Justin_o - I'd call it pretty bizarre

[15:16:33 CDT(-0500)] <Justin_o> so bizzare({})

[15:17:39 CDT(-0500)] <Justin_o> it really is pretty strange

[15:19:00 CDT(-0500)] <Bosmon> Why do you need to flatten them out into an array like that?

[15:19:07 CDT(-0500)] <Bosmon> The odd thing is the alternation of keys and values

[15:19:11 CDT(-0500)] <Bosmon> Which is really pretty unnattural

[15:19:29 CDT(-0500)] <Justin_o> the command line arguments need to be passed as a list (like an array) of the arguments

[15:20:01 CDT(-0500)] <Justin_o> Bosmon: ^

[15:20:10 CDT(-0500)] <Bosmon> Justin_o, yes

[15:20:23 CDT(-0500)] <Bosmon> But why do they take this form, derived from query parameters in this way?

[15:20:26 CDT(-0500)] <Justin_o> and i agree really unnatural.. any other suggestions on how i might make this translation more normal

[15:21:04 CDT(-0500)] <Justin_o> when they run through the cherrypy served the values are passed in as query parameters.. cherrypy passes these along as a dictionary

[15:21:19 CDT(-0500)] <Bosmon> Justin_o - yes, but how do they come to be this way?

[15:21:27 CDT(-0500)] <Justin_o> hmm.. not sure what you mean

[15:21:36 CDT(-0500)] <Bosmon> WHO derived the query parameter format!

[15:21:39 CDT(-0500)] <Justin_o> i suppose though some interal workings of cherrypy

[15:21:41 CDT(-0500)] <Justin_o> ah

[15:21:48 CDT(-0500)] <Justin_o> i suppose that would be me

[15:21:53 CDT(-0500)] <Bosmon> Well then!

[15:21:57 CDT(-0500)] <Bosmon> Why did you do it that way

[15:22:32 CDT(-0500)] <Justin_o> Bosmon: they are at the bottom of this page

[15:22:33 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Proposed+Decapod+Export+Server+Architecture

[15:23:06 CDT(-0500)] <Justin_o> it seemed most sensible to the users.. otherwise i suppose i could ask them for a options=[list] something like that

[15:23:27 CDT(-0500)] <Bosmon> Ok

[15:23:34 CDT(-0500)] <Bosmon> I guess those do look relatively natural

[15:23:44 CDT(-0500)] <Bosmon> On the other hand, these URL segments with apostrophes in them don't : P

[15:24:00 CDT(-0500)] <colinclark> the apostrophes are placeholder marks, I believe

[15:24:05 CDT(-0500)] <Bosmon> Ah ok

[15:24:09 CDT(-0500)] <colinclark> as in

[15:24:13 CDT(-0500)] <colinclark> 'insert book name here'.pdf

[15:24:58 CDT(-0500)] <Justin_o> colinclark, Bosmon: yes.. they are sort of the variable path segments..

[15:25:02 CDT(-0500)] <Bosmon> Ok, and the command line call doesn't have any punctuation associating keys with values?

[15:25:14 CDT(-0500)] <Bosmon> "bit = 24" etc.?

[15:25:37 CDT(-0500)] <Justin_o> Bosmon: nope, just position from what i gather

[15:25:44 CDT(-0500)] <Bosmon> Ok

[15:25:52 CDT(-0500)] <Bosmon> Well, you'll just have to write something that does this

[15:26:03 CDT(-0500)] <Bosmon> There's nothing in the framework that assists you to interleave keys with values in this way

[15:26:12 CDT(-0500)] <Bosmon> And it doesn't seem a sufficiently general use case to produce something

[15:26:21 CDT(-0500)] <Bosmon> You'll just have to accumulate something with a fluid.each call

[15:26:31 CDT(-0500)] <Justin_o> Bosmon: no problem.. i'm writing this in python anyways.. actually i already have it, but the name is terrible

[15:27:01 CDT(-0500)] <Justin_o> well.. can't think of a decent name anyway as..

[15:27:04 CDT(-0500)] <Justin_o> anways

[15:27:15 CDT(-0500)] <Bosmon> It isn't called something like queryDictionaryToCommandLine? : P

[15:27:53 CDT(-0500)] <Justin_o> that might be better.. it was called dictToFlagList

[15:28:17 CDT(-0500)] <Justin_o> now i was thinking of calling it explodeToList

[15:28:31 CDT(-0500)] <colinclark> interleave()?

[15:28:52 CDT(-0500)] <Justin_o> colinclark: interesting.. that might be better.. sort of what it does

[15:30:25 CDT(-0500)] <Justin_o> colinclark: how about weave?

[15:30:43 CDT(-0500)] <colinclark> it depends how creative you want to get

[15:30:57 CDT(-0500)] <Justin_o> lol

[15:30:58 CDT(-0500)] <Justin_o> okay

[15:30:59 CDT(-0500)] <colinclark> I suspect weave is a bit more "abstract"

[15:31:26 CDT(-0500)] <colinclark> I guess this is just a free function you've defined somewhere?

[15:31:34 CDT(-0500)] <colinclark> or is it a method on something?

[15:32:00 CDT(-0500)] <Justin_o> it was in the utilities, but we are separating the into classes now so that they are grouped together better

[15:45:13 CDT(-0500)] <michelled> Bosmon: Justin_o and I were wondering if you'd like to talk about your plans for improving the framework at the community meeting this week

[15:45:33 CDT(-0500)] <Bosmon> michelled - I could try, but I will probably be away at that time

[15:45:59 CDT(-0500)] <michelled> oh, right - perhaps we'd best leave it for another time then

[15:46:35 CDT(-0500)] <michelled> fluid-everyone: does anyone have a idea for a topic for this week's community meeting?

[15:46:59 CDT(-0500)] <colinclark> I could teach you all how to make music in JavaScript

[15:47:05 CDT(-0500)] <michelled> given the short notice, it would have to be an informal meeting, a conversation or design or code tour perhaps

[15:47:10 CDT(-0500)] <colinclark> that'd be better

[15:47:26 CDT(-0500)] <michelled> colinclark: music in javascript sounds fun

[15:47:53 CDT(-0500)] <michelled> I guess you could show us thealphanerds project if you felt like it

[15:50:53 CDT(-0500)] <colinclark> we could all just play his keyboard for an hour

[15:51:02 CDT(-0500)] <colinclark> start a band