fluid-work IRC Logs-2010-07-14

[04:02:50 CDT(-0500)] * kasper (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[05:16:33 CDT(-0500)] * kasper (~kasper@h55eb1717.dkkobye.sta.perspektivbredband.net) has joined #fluid-work
[07:36:08 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[08:08:07 CDT(-0500)] * yura_ (~yura@142.150.154.163) has joined #fluid-work
[08:31:31 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176444194.dsl.bell.ca) has joined #fluid-work
[08:37:26 CDT(-0500)] * sgithens (~sgithens@149-166-10-223.dhcp-in.iupui.edu) has joined #fluid-work
[08:44:47 CDT(-0500)] * michelled (~michelled@142.150.154.141) has joined #fluid-work
[08:54:58 CDT(-0500)] * clown (~clown@142.150.154.130) has joined #fluid-work
[08:58:52 CDT(-0500)] <jamon> colinclark, Justin_o, any more thoughts on migrating to redmine? i can setup a test instance again for you two (or anyone else for that matter) to explore
[09:00:11 CDT(-0500)] <Justin_o> jamon: i haven't had much time lately to think about it, but if you have free time to setup a test instance for us I think that would be good... are you able to import in from jira? I can't remember what the conclusion was about this.
[09:00:41 CDT(-0500)] <jamon> Justin_o: yeah, i can get everything except vulab
[09:01:22 CDT(-0500)] <Justin_o> jamon: right... okay.. sure... i wouldn't mind seeing how it looks and works with our stuff
[09:04:31 CDT(-0500)] * mackrauss (~Armin@142.150.154.130) has joined #fluid-work
[09:05:26 CDT(-0500)] * EricDalquist (~dalquist@2607:f388:e:0:221:9bff:fe37:e768) has joined #fluid-work
[09:13:50 CDT(-0500)] <mackrauss> Hey Justin_o is the Ubuntu installation what you needed? Anything missing?
[09:14:17 CDT(-0500)] <Justin_o> mackrauss: Yes... it seemed to be all working... thanks for setting that up to us
[09:21:08 CDT(-0500)] <yura_> colinclark: do you have a second?
[09:21:31 CDT(-0500)] <colinclark> yura_: on a call at the moment, but i should be free momentarily
[09:21:51 CDT(-0500)] <yura_> alright
[09:43:43 CDT(-0500)] <colinclark> yura_: What's up?
[09:44:03 CDT(-0500)] <yura_> colinclark: I was trying to find the reference to that conversation about json schema from last week
[09:44:30 CDT(-0500)] <colinclark> eek, yes
[09:44:30 CDT(-0500)] <yura_> couldn't find it in the logs though. I think you mentioned some specific project worth looking at
[09:44:37 CDT(-0500)] <colinclark> That was a verbal conversation
[09:44:40 CDT(-0500)] <yura_> oh
[09:44:48 CDT(-0500)] <colinclark> The discussion about Repeatable was, if you remember, here in this channel
[09:44:52 CDT(-0500)] <yura_> yes
[09:44:55 CDT(-0500)] <colinclark> JSON Schema was something AC asked me about in the office
[09:44:59 CDT(-0500)] <colinclark> So I can summarize if you'd like
[09:45:17 CDT(-0500)] <yura_> yes, that would be great, it is kind of related (some repeatable bugs)
[09:45:55 CDT(-0500)] <colinclark> Here's the JSON Schema draft spec: http://tools.ietf.org/html/draft-zyp-json-schema-02
[09:46:02 CDT(-0500)] <colinclark> It contains all sorts of things that I don't think we need
[09:46:25 CDT(-0500)] <yura_> right
[09:46:27 CDT(-0500)] <yura_> i found that
[09:46:27 CDT(-0500)] <colinclark> The alternative style of schema we considered was just a series of EL paths on the left, with type information on the right
[09:46:30 CDT(-0500)] <colinclark> so like this...
[09:46:57 CDT(-0500)]

[09:47:13 CDT(-0500)] <colinclark> Which I can imagine might be convenient for cases where you've got an EL path and need to check its type
[09:47:27 CDT(-0500)] <colinclark> Perhaps harder to recurse through and build up, say, an empty model conforming to the type information
[09:47:41 CDT(-0500)] <colinclark> All we really need to know at the moment is which properties are arrays
[09:47:49 CDT(-0500)] <colinclark> JSON Schema doesn't strike me as especially good or bad
[09:48:00 CDT(-0500)] <colinclark> It has a lot of validation-related stuff that we really don't need in it
[09:48:07 CDT(-0500)] <yura_> right
[09:48:09 CDT(-0500)] <colinclark> But the core structure and type definitions should be just fine for our needs
[09:48:19 CDT(-0500)] <colinclark> And since it's already there, I don't see any reason not to support it
[09:49:18 CDT(-0500)] <yura_> but are there any resources with the functionality that we need , i.e. recreating a model from schema
[09:49:29 CDT(-0500)] <yura_> empty model / schema that is
[09:52:08 CDT(-0500)] <yura_> i couldn't yet find anything like that, meaning we would have to write it, is that right?
[09:53:06 CDT(-0500)] <colinclark> yura_: Yep
[09:53:23 CDT(-0500)] <colinclark> We'd have to walk the schema and build up a model accordingly
[09:53:52 CDT(-0500)] <colinclark> Interestingly, I can imagine that we really just want to know about arrays, in which case we should just ignore anything that isn't an object or an array and just build up the rest
[09:53:55 CDT(-0500)] <colinclark> If that makes sense
[09:54:07 CDT(-0500)] <yura_> yes, totally
[09:54:09 CDT(-0500)] <yura_> thanks
[09:54:15 CDT(-0500)] <colinclark> any time
[09:54:26 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[10:40:50 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[10:58:36 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[11:19:41 CDT(-0500)] <Justin_o> colinclark, jameswy: the bug parade e-mail has been sent to the decapod list
[11:19:51 CDT(-0500)] <jameswy> Justin_o: thanks
[11:19:53 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work
[11:28:37 CDT(-0500)] <athena> anyone have a minute to explain how radio buttons are supposed to work in the renderer?
[11:50:51 CDT(-0500)] <colinclark> athena: Rendering radio buttons, you mean?
[11:51:16 CDT(-0500)] <colinclark> As in, how to do so?
[11:52:54 CDT(-0500)] <athena> yeah
[11:53:03 CDT(-0500)] <athena> i mean, i have them rendering right now, but i think i'm doing it wrong
[11:53:26 CDT(-0500)] <athena> it's overriding the name attribute with things like "layoutOptionsContainer::layoutOptionGroup:2:layoutOption:1:layoutSelector"
[11:54:03 CDT(-0500)] <athena> i looked at the documentation here and it looks like maybe i should be using some sort of special SelectChoice instead? http://wiki.fluidproject.org/display/fluid/Renderer+Component+Types
[11:54:35 CDT(-0500)] <colinclark> athena: Yep, SelectChoice is what you need
[11:54:40 CDT(-0500)] <colinclark> Radio buttons are sort of funny...
[11:54:58 CDT(-0500)] <colinclark> So you are probably already familiar with Select, which you typically peer to things like a pop-up list
[11:55:14 CDT(-0500)] <colinclark> With radio buttons, you create a Select that isn't actually peered to any markup in the template
[11:55:15 CDT(-0500)] <athena> so it looks like maybe it needs a parent select control? what does that typically correspond to with a radio button?
[11:55:18 CDT(-0500)] <athena> gotcha
[11:55:21 CDT(-0500)] <colinclark> It's just floating there to whole the selection state
[11:55:30 CDT(-0500)] <athena> that makes sense
[11:55:36 CDT(-0500)] <colinclark> And then you create SelectChoices for each radio button, and set the parent to the select control
[11:55:38 CDT(-0500)] <colinclark> yep, you've got it
[11:55:43 CDT(-0500)] <colinclark> Let me get you an example
[11:55:50 CDT(-0500)] <athena> so the complicating factor here is that my radio buttons are actually grouped in repeating elements
[11:55:51 CDT(-0500)] <colinclark> I think we have a demo that shows it well enough
[11:56:05 CDT(-0500)] <colinclark> I have started on a whole new set of Renderer tutorials, but it's got a long way to go
[11:56:13 CDT(-0500)] <athena> so they're actually in separate subcontainers in my component tree - is that likely to be a problem?
[11:56:17 CDT(-0500)] <colinclark> athena: That shouldn't bee too much of a problem, no
[11:56:20 CDT(-0500)] <athena> oh good
[11:56:26 CDT(-0500)] <athena> that's excellent news
[11:56:31 CDT(-0500)] <athena> i'll try all this out and see how it goes
[11:56:37 CDT(-0500)] <colinclark> So this demo includes radio buttons: http://build.fluidproject.org/infusion/demos/renderer/demo.html
[11:56:45 CDT(-0500)] <colinclark> It can be a bit confusing because it includes other things
[11:56:58 CDT(-0500)] <colinclark> But you can see the important things here
[11:57:11 CDT(-0500)] <athena> thanks!
[11:57:28 CDT(-0500)] <colinclark> buildCanapeListSubtree() has the action...
[11:57:46 CDT(-0500)] <colinclark> So you can see that we start by creating a Select component
[11:57:51 CDT(-0500)] <colinclark> (called "canapes")
[11:58:08 CDT(-0500)] <athena> i see it, that makes sense
[11:58:10 CDT(-0500)] <athena> by the way, did you see my note the other day about refreshing the reorderer?
[11:58:11 CDT(-0500)] <colinclark> And then we transform through the data, creating SelectChoices for each thing
[11:58:19 CDT(-0500)] <colinclark> This uses checkboxes, but it should be the same as a radio button
[11:58:24 CDT(-0500)] <colinclark> athena: No, I don't think I did
[11:58:26 CDT(-0500)] <athena> makes sense
[11:58:30 CDT(-0500)] <colinclark> Was it by email, or in the channel?
[11:58:34 CDT(-0500)] <athena> in the channel
[11:58:40 CDT(-0500)] <colinclark> Nope, I missed it. What's up?
[11:59:10 CDT(-0500)] <athena> it seems like when i change the list of locked items they don't refresh correctly
[11:59:33 CDT(-0500)] <athena> i see them in the selectables list, or not, as appropriate, but they're not actually draggable, and some of the relevant CSS classes aren't applied/removed
[11:59:59 CDT(-0500)] <athena> is that something you'd expect to work?
[12:00:11 CDT(-0500)] <colinclark> hmm
[12:00:15 CDT(-0500)] <colinclark> that sounds fairly buggy
[12:00:30 CDT(-0500)] <colinclark> You're calling Reorderer's refresh method, right?
[12:00:33 CDT(-0500)] <athena> yeah
[12:00:41 CDT(-0500)] <colinclark> That sounds like a bug
[12:00:42 CDT(-0500)] <athena> and that's always worked fine for removing elements and such
[12:00:44 CDT(-0500)] <athena> ok
[12:00:59 CDT(-0500)] <athena> i'll isolate the code to demonstrate it and file a JIRA
[12:01:26 CDT(-0500)] <athena> we're in the middle of moving a lot of the uportal code to fluid components
[12:01:34 CDT(-0500)] <colinclark> ah, that's cool
[12:01:37 CDT(-0500)] <athena> i'm really looking forward to having that code be more manageable
[12:01:37 CDT(-0500)] <colinclark> thanks for filing the JIRA
[12:01:41 CDT(-0500)] <athena> sure
[12:01:52 CDT(-0500)] <athena> i think it'll make it easier to customize too, since the markup won't be so fixed
[12:02:37 CDT(-0500)] <colinclark> that'll be great
[12:06:14 CDT(-0500)] <colinclark> Justin_o: It seems to me that DECA-135 and DECA-136 might count as blockers for Decapod 0.4...
[12:06:23 CDT(-0500)] <colinclark> Without them, the calibration page doesn't work.
[12:06:28 CDT(-0500)] <colinclark> What do you think?
[12:06:48 CDT(-0500)] <Justin_o> colinclark: okay... i'll update those
[12:07:15 CDT(-0500)] <Justin_o> colinclark: also wondering about how to support i18n for the page title... since it technically lives outside the scope of the component...
[12:07:46 CDT(-0500)] <colinclark> yeah, although it does live in a definitive scope...
[12:07:59 CDT(-0500)] <colinclark> In that there is only one page title, ever.
[12:08:44 CDT(-0500)] <Justin_o> colinclark: yep, but what if two components on a page wanted to affect the title...
[12:08:54 CDT(-0500)] <colinclark> Then they'd have to duke it out
[12:09:00 CDT(-0500)] <colinclark> This is sort of a design decision here...
[12:09:10 CDT(-0500)] <Justin_o> although i would assume that in the case of decapod we don't really need to worry...
[12:09:12 CDT(-0500)] <colinclark> We're promoting certain components to page level
[12:09:28 CDT(-0500)] <colinclark> If the component was truly built to be embedded in multiple places and pages
[12:09:32 CDT(-0500)] <Justin_o> colinclark: yep... this is sort of what i'm wondering about... the design of it
[12:09:46 CDT(-0500)] <colinclark> We'd clearly have to remove the responsibility for page titles and put that into a component that was responsible for the page as a whole
[12:10:35 CDT(-0500)] <Justin_o> colinclark: yes... i suppose the only place where we may have overlap at somepoint would be with the cameraMessage component if it were to become a subcomponent of capture
[12:11:06 CDT(-0500)] <Justin_o> maybe the navigationBar should be defining the title, when we have a component for that
[12:11:55 CDT(-0500)] <colinclark> There is certainly some stuff that represents "chrome"
[12:12:04 CDT(-0500)] <colinclark> and which may well be best suited to render the page title
[12:12:19 CDT(-0500)] <colinclark> The navigation bar being an obvious immediate example, yes
[12:12:23 CDT(-0500)] <colinclark> That makes a lot of sense to me
[12:13:44 CDT(-0500)] <Justin_o> colinclark: okay... any suggestions on what approach to take for 0.4. I don't think it makes sense to put them into the current components just to rip them out later and put them in the proper place. since we have no components for any part of the chrome at the moment.
[12:14:06 CDT(-0500)] <Justin_o> we could just not support i18n for page titles for 0.4 or we could just have a function or something to set it...
[12:14:41 CDT(-0500)] <colinclark> Where would the data come from for the function?
[12:15:18 CDT(-0500)] <Justin_o> colinclark: yep that's a good question... we could use a json file or have an object in the decapodUtils directory
[12:15:23 CDT(-0500)] <Justin_o> not directory, file
[12:15:34 CDT(-0500)] <colinclark> yeah
[12:15:43 CDT(-0500)] <colinclark> I suppose that's the very simplest approach for now
[12:16:25 CDT(-0500)] <colinclark> decapodUtils.js is already one of those classic "utils" anti-patterns
[12:16:32 CDT(-0500)] <colinclark> It is just filled with stuff
[12:16:41 CDT(-0500)] * laurel (~laurel@dsl-173-206-221-30.tor.primus.ca) has joined #fluid-work
[12:17:05 CDT(-0500)] <Justin_o> i should rename it to decapodWorkShed
[12:17:09 CDT(-0500)] <colinclark>
[12:17:19 CDT(-0500)] <colinclark> I'd be tempted to take that bit of navbar-related functionality
[12:17:22 CDT(-0500)] <colinclark> make a small component for it
[12:17:30 CDT(-0500)] <colinclark> and include page titles in there
[12:17:41 CDT(-0500)] <colinclark> why is the rotationInDegrees function a util?
[12:17:50 CDT(-0500)] <Justin_o> colinclark: yep that makes sense
[12:18:01 CDT(-0500)] <athena> colinclark: is there any documentation on how the whole relative component id thing works?
[12:18:03 CDT(-0500)] <Justin_o> the rotationDegrees function is a util because two components use it
[12:18:11 CDT(-0500)] <colinclark> athena: Not that I know of
[12:18:26 CDT(-0500)] <colinclark> It's a path-like structure reflecting containment in the component tree
[12:18:31 CDT(-0500)] <colinclark> It's really a hideous thing
[12:18:32 CDT(-0500)] <athena> i tried parentFullID, but that threw an error of "getAbsoluteComponent is not defined"
[12:19:07 CDT(-0500)] <colinclark> Do you know where your parent Select component is, relative to the SelectChoice?
[12:19:09 CDT(-0500)] <athena> so does "..::canapes" mean like one level up or something?
[12:19:09 CDT(-0500)] <Justin_o> colinclark: i guess it could just be a public function in the imageRotater component
[12:19:14 CDT(-0500)] <athena> yes, it's two levels up
[12:19:48 CDT(-0500)] <colinclark> so your parentRelativeID should be, if I remember correctly, "..::..::<id of Select>"
[12:19:52 CDT(-0500)] <colinclark> How's that for dots and colons?
[12:20:02 CDT(-0500)] <athena> ooh wow, it works
[12:20:09 CDT(-0500)] <athena> and actually it turned out to be three levels up
[12:20:16 CDT(-0500)] <athena> "..::..::..::layoutOptions"
[12:20:19 CDT(-0500)] <colinclark> This is one of my biggest Renderer pet peeves, as you might be able to guess
[12:20:20 CDT(-0500)] <athena> i'm programming in morse code!!
[12:20:23 CDT(-0500)] <colinclark> lol
[12:20:25 CDT(-0500)] <colinclark> !!!
[12:20:30 CDT(-0500)] <colinclark>
[12:20:51 CDT(-0500)] * athena worries that little ants are going to come eat all the relativity dots
[12:21:02 CDT(-0500)] <colinclark> lol
[12:21:08 CDT(-0500)] <athena> anyway, it actually works, and the error message about it not being found was actually really helpful
[12:21:12 CDT(-0500)] <athena> thanks for the pointers!
[12:21:16 CDT(-0500)] <colinclark> any time
[12:21:17 CDT(-0500)] <colinclark> glad it works
[12:21:19 CDT(-0500)] <colinclark> sorry for all the dots
[12:21:41 CDT(-0500)] <colinclark> Justin_o: sorry, just recovering from laughing at athena's Renderer jokes
[12:21:59 CDT(-0500)] <athena> i can live with it as long as the code works in the end
[12:22:18 CDT(-0500)] <colinclark> what are the two components that use rotationDegrees(), Justin_o?
[12:22:32 CDT(-0500)] <Justin_o> imageRotater and the cameraSetup components
[12:22:35 CDT(-0500)] <colinclark> athena: I guess that's a good first step
[12:22:44 CDT(-0500)] <colinclark> what does cameraSetup do with it?
[12:22:49 CDT(-0500)] <colinclark> I guess I should be reading the code
[12:22:58 CDT(-0500)] <colinclark> maybe you can give me a little tour in a few minutes when this CSpace call ends
[12:23:02 CDT(-0500)] <colinclark> if you have the time
[12:23:34 CDT(-0500)] <colinclark> Justin_o: ^
[12:24:26 CDT(-0500)] <Justin_o> colinclark: sure
[12:24:32 CDT(-0500)] <colinclark> k, cool
[12:24:34 CDT(-0500)] <colinclark> it's just winding down now
[12:24:46 CDT(-0500)] <Justin_o> colinclark: okay.. message me whenever you are ready
[12:26:54 CDT(-0500)] <colinclark> Justin_o: ready when you are
[12:27:17 CDT(-0500)] <Justin_o> colinclark: ready... skype?
[12:57:21 CDT(-0500)] <jameswy> Justin_o: I created a couple of JIRAs for missing images (DECA-141, 142).
[13:04:43 CDT(-0500)] * jhung (~decapod@H58.C206.cci.switchworks.net) has joined #fluid-work
[13:10:34 CDT(-0500)] <yura_> colinclark: do you have a second for another quetsion?
[13:10:37 CDT(-0500)] <yura_> question
[13:12:29 CDT(-0500)] <colinclark> yura_: On a call, but should be free in a few minutes
[13:12:43 CDT(-0500)] <yura_> thanks
[13:40:02 CDT(-0500)] <jhung> colinclark, justin_o: does the install script pull the latest changes, or will I need to manually pull from master and/or colinclark's repo as well?
[13:41:44 CDT(-0500)] <colinclark> jhung: one sec
[13:42:00 CDT(-0500)] <colinclark> So, I changed the install scripts a bit recently
[13:42:14 CDT(-0500)] <colinclark> They now live inside the default repository
[13:42:26 CDT(-0500)] <colinclark> So you need to check out default first, then run the install scripts
[13:42:43 CDT(-0500)] <jhung> okay. By "default" you mean the google code site.
[13:49:08 CDT(-0500)] <colinclark> I mean the default repository on the google site, yep
[13:57:14 CDT(-0500)] <Justin_o> jameswy: thanks... are you hoping they make it onto bug parade?
[13:57:46 CDT(-0500)] <jameswy> Justin_o: You tell me! (they're really quick fixes)
[13:57:50 CDT(-0500)] * laurel (~laurel@dsl-173-206-221-30.tor.primus.ca) has joined #fluid-work
[13:58:03 CDT(-0500)] <colinclark> hey yura_
[13:58:09 CDT(-0500)] <yura_> hey colinclark
[13:58:15 CDT(-0500)] <colinclark> sorry for the delay, i'm free now if you still have a question
[13:58:29 CDT(-0500)] <Justin_o> jameswy: i suppose the question is how important do you think they are for this release... it would be interesting to hear colinclark and jhung's thoughts too
[13:58:29 CDT(-0500)] <yura_> i think i m good , just needed to figure something out
[13:58:32 CDT(-0500)] <yura_> thanks though
[13:58:33 CDT(-0500)] <colinclark> cool
[13:59:25 CDT(-0500)] * colinclark is just looking at DECA-141 and 142
[13:59:52 CDT(-0500)] <jameswy> Justin_o, colinclark, jhung: at least one of the missing/mis-path'd images is cause for greater-than-aesthetic concern: it was a progress spinner--without it, users might not be sure whether they're supposed to be waiting, or if the system just broke.
[14:00:08 CDT(-0500)] <colinclark> I don't see any reason not to fix issues like this
[14:00:21 CDT(-0500)] <colinclark> I might even have an umbrella issue for them related to pathing and styling tweaks
[14:01:23 CDT(-0500)] <jhung> colinclark: yes there should be tweaking done once we have an end to end product in place since some styles don't appear until certain states are achieved.
[14:01:34 CDT(-0500)] <Justin_o> colinclark: i'm fine with that as long as we don't get too hung up on styling tweaks
[14:01:44 CDT(-0500)] <colinclark> good point, king
[14:01:59 CDT(-0500)] <colinclark> as long as we're thoughtful about it, it should be fine
[14:02:30 CDT(-0500)] <jhung> k
[14:02:46 CDT(-0500)] <Justin_o> colinclark: okay... i'll add a new jira for that and add DECA-141 and DECA-142 to the parade
[14:02:59 CDT(-0500)] <colinclark> great
[14:03:12 CDT(-0500)] <colinclark> Justin_o: I put up our little refactoring patch here: http://issues.fluidproject.org/browse/DECA-132
[14:03:25 CDT(-0500)] <Justin_o> colinclark: thanks
[14:03:29 CDT(-0500)] <colinclark> Hopefully it will apply
[14:04:21 CDT(-0500)] <Justin_o> if i'm lucky but since i'm in the process of renaming some of the files related to calibration... i'm not confident
[14:04:56 CDT(-0500)] <colinclark> eek
[14:05:52 CDT(-0500)] <colinclark> So I'm going to do a first pass at camera calibration that uses the camera's port as its unique id, realizing that this will break very quickly
[14:05:52 CDT(-0500)] <colinclark> t
[14:06:00 CDT(-0500)] <colinclark> Then try to write a regexp that can scrape out serial numbers
[14:06:02 CDT(-0500)] <jhung> colinclark, justin_o: I can't seem to kill my python processes from previous server executions. kill #pid doesn't seem to work.
[14:06:17 CDT(-0500)] <colinclark> kill -9 <pid> should work
[14:07:14 CDT(-0500)] <colinclark> I will try to add a real start/stop script for 0.5
[14:09:44 CDT(-0500)] <colinclark> jhung: any luck?
[14:09:50 CDT(-0500)] <jameswy> Justin_o, jhung, colinclark: I just pushed fixes to 141 and 142 to my repo.
[14:20:41 CDT(-0500)] <colinclark> Justin_o: Quick question
[14:20:54 CDT(-0500)] <colinclark> When you POST back a calibration model, the entire request data is the calibration model, right?
[14:21:41 CDT(-0500)] <Justin_o> yes
[14:21:43 CDT(-0500)] <Justin_o> should be
[14:25:01 CDT(-0500)] * jhung (~decapod@H58.C206.cci.switchworks.net) has joined #fluid-work
[14:30:33 CDT(-0500)] <Justin_o> colinclark: will the calibration service remain as calibration or will that change its name to independentLeftRight as well
[14:36:23 CDT(-0500)] <jhung> colinclark, justin_o: how do I configure the server so it will use the mock images directory when I press capture?
[14:42:56 CDT(-0500)] <colinclark> Justin_o: I'm going to leave it as /calibration for now, since it's not fully clear how much the model will actually change in the long run
[14:42:56 CDT(-0500)] <colinclark> T
[14:43:03 CDT(-0500)] <colinclark> The real behaviour is on the client side anyway
[14:43:17 CDT(-0500)] <colinclark> jhung: Start up the server with --no-cameras
[14:43:30 CDT(-0500)] <jhung> colinclark: thanks!
[14:46:09 CDT(-0500)] <jhung> justin_o: I've punted DECA-54 over to you. Still an issue in Ubuntu 9.10, FF3.6
[14:47:32 CDT(-0500)] * kasper (~kasper@0x5552c030.adsl.cybercity.dk) has joined #fluid-work
[14:47:42 CDT(-0500)] <Justin_o> colinclark: thanks
[14:48:07 CDT(-0500)] <Justin_o> jhung: okay so that one should be on bug parade then
[14:48:14 CDT(-0500)] <Justin_o> i'll move it up
[14:48:17 CDT(-0500)] <jhung> k
[15:13:40 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has left #fluid-work
[15:27:46 CDT(-0500)] * mackrauss (~Armin@142.150.154.130) has joined #fluid-work
[15:33:27 CDT(-0500)] * clown (~clown@142.150.154.130) has joined #fluid-work
[15:34:33 CDT(-0500)] * jhung (~decapod@H58.C206.cci.switchworks.net) has left #fluid-work
[15:44:32 CDT(-0500)] <colinclark> hey jameswy, do you know about the font stylesheet we link to from googleapis?
[15:57:03 CDT(-0500)] * athena (~athena@c-76-121-97-221.hsd1.wa.comcast.net) has joined #fluid-work
[15:59:26 CDT(-0500)] * mackrauss (~Armin@142.150.154.130) has joined #fluid-work
[16:13:15 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[16:28:36 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[16:38:56 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[17:12:02 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[20:53:41 CDT(-0500)] * jhung (~Jon@H58.C206.cci.switchworks.net) has joined #fluid-work
[20:53:43 CDT(-0500)] * jhung (~Jon@H58.C206.cci.switchworks.net) has left #fluid-work