fluid-work IRC Logs-2012-07-25

[08:13:16 CDT(-0500)] <helipus> Hi guys, is this channel for the typo3 fluid framework which comes with extbase?

[08:18:06 CDT(-0500)]

[08:18:06 CDT(-0500)]

[08:18:06 CDT(-0500)] <helipus> the idea is to append "<br />" to every foreach item except the last

[08:18:24 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)

[08:51:42 CDT(-0500)] <anastasiac> michelled, regarding FLOE-17, images that don't respond to UIO: Are the changes you've made merged into a11y-uio yet, or are you waiting for 660?

[08:53:11 CDT(-0500)] <michelled> anastasiac: I think 660 was that last thing outstanding - did you find other issues?

[08:54:21 CDT(-0500)] <anastasiac> michelled, I'm looking at the basic browse interface in high-contrast, and the small graphic beside the license info (e.g. "Share only" or "Remix and share" is not high contrast. Is that a known issue?

[08:55:01 CDT(-0500)] <michelled> yeah - 17 was about buttons, right?

[08:55:16 CDT(-0500)] <michelled> anastasiac: I think the other issues are covered in 43

[08:55:40 CDT(-0500)] <michelled> other than facebook, twitter and google + which has its own JIRA

[08:55:49 CDT(-0500)] <anastasiac> ah, right, I'm getting my JIRAs confused. And 43 is not yet merged into a11y-uio, right?

[08:56:53 CDT(-0500)] <michelled> anastasiac: most of 43 is - but there are a lot of details that are not done yet

[08:57:10 CDT(-0500)] <anastasiac> ok, michelled, just trying to figure out the best thing to work on today

[08:57:35 CDT(-0500)] <michelled> anastasiac: I think 12 or 46 make the most sense

[08:57:40 CDT(-0500)] <michelled> since I'm working on 43 still

[08:57:52 CDT(-0500)] <anastasiac> k, I'll check in with Joanna

[09:00:09 CDT(-0500)] <michelled> anastasiac: if you'd rather work on 43, you can take on a part of the UI

[09:00:19 CDT(-0500)] <anastasiac> no, no problem michelled

[09:06:21 CDT(-0500)] <michelled> anastasiac: I noticed another issue that we need to fix - I don't think there's a JIRA for it yet. On the preview, the learner options tab is on the wrong side of the user drop down

[09:06:45 CDT(-0500)] <anastasiac> ok, michelled, I'll file that one

[09:06:54 CDT(-0500)] <michelled> anastasiac: and another - there is a scroll bar on the main content in the authoring tool in high contrast

[09:07:12 CDT(-0500)] <anastasiac> michelled, is the scrollbar not there in the default theme?

[09:07:51 CDT(-0500)] <michelled> I don't think so - I don't have a working system at the moment so I can't check

[09:08:58 CDT(-0500)] <anastasiac> k

[09:26:51 CDT(-0500)] <Justin_o> michelled: i'm in a bit of bind for something in decapod… wondering if you might have some thoughts on how to do something

[09:27:09 CDT(-0500)] <michelled> what's going on Justin_o?

[09:27:24 CDT(-0500)] <Justin_o> michelled: okay.. here's the design.. http://issues.fluidproject.org/secure/attachment/12577/Decapod+0.6+Export-14.png

[09:27:39 CDT(-0500)] <Justin_o> michelled: i'm working on the bottom portion. when the user enters an invalid value

[09:28:12 CDT(-0500)] <michelled> ok

[09:28:26 CDT(-0500)] <Justin_o> michelled: so i had wanted to use the tooltip wrapper component we have in infusion.. the way it works is that a jQuery UI tooltip is created on the wrappers container

[09:28:43 CDT(-0500)] <michelled> right

[09:28:54 CDT(-0500)] <Justin_o> the issue i'm having is that i only want this tooltip to show up when the field with the invalid input has focus

[09:29:49 CDT(-0500)] <michelled> and right now when does it shoe?

[09:29:50 CDT(-0500)] <Justin_o> michelled: so the question is, how do i create it.. since the need for it will be sort of dynamic

[09:29:50 CDT(-0500)] <michelled> show?

[09:30:07 CDT(-0500)] <Justin_o> michelled: i haven't yet added it

[09:30:46 CDT(-0500)] <Justin_o> michelled: also those inputs are rendered based on a model passed into the component

[09:31:34 CDT(-0500)] <michelled> Justin_o: I guess you could lazily create it if you want - but regardless of when you create it you'll have to customize your 'show' so it only happens on error

[09:31:42 CDT(-0500)] <Justin_o> so i guess it would make the most sense for it to be added by the renderer, but it's only supposed to show on error

[09:32:26 CDT(-0500)] <michelled> yeah, I think you're going to have to over ride the default show behaviour - is there an easy way to do that?

[09:33:10 CDT(-0500)] <Justin_o> michelled: here's the wrapper code https://github.com/fluid-project/infusion/blob/master/src/webapp/components/tooltip/js/Tooltip.js

[09:33:22 CDT(-0500)] <helipus> Hi guys, I want to report a bug for the f:link.external view helper. Can you point me to th eplace or to someone?

[09:34:45 CDT(-0500)] <michelled> helipus: hi there, I'm not sure what you're referring to - is this in Infusion?

[09:34:48 CDT(-0500)] <Justin_o> michelled: here's the tooltip plugin code https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/plugins/tooltip/js/jquery.ui.tooltip.js

[09:35:31 CDT(-0500)] <helipus> typo3 fluid?

[09:36:38 CDT(-0500)] <helipus> michelled: so sorry if this is not the right irc channel

[09:37:02 CDT(-0500)] <michelled> helipus: is think it's the wrong room

[09:37:11 CDT(-0500)] <helipus> thx anyway

[09:37:14 CDT(-0500)] <helipus> bye

[09:38:13 CDT(-0500)] <Justin_o> michelled: so it looks like i can drill down into the plugin code and disable it, then enable it when there is an error

[09:38:27 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/plugins/tooltip/js/jquery.ui.tooltip.js#L53-59

[09:38:38 CDT(-0500)] <Justin_o> michelled: i guess that's the best way.. what do you think?

[09:39:09 CDT(-0500)] <michelled> Justin_o: that seems so invasive but you might not have an option if you are using the tooltip plugin

[09:39:29 CDT(-0500)] <michelled> Justin_o: I'm sorry - I need to go off line for a bit - we can talk more about it later?

[09:39:51 CDT(-0500)] <Justin_o> michelled: no problem.. i'll try this approach out and see how it goes

[09:40:55 CDT(-0500)] <michelled> cool ttyl

[10:06:11 CDT(-0500)] <Justin_o> anastasiac: do you happen to remember if there is a way to use non-autoInit components within an IoC component?

[10:06:47 CDT(-0500)] <anastasiac> Justin_o, I think you just have to call initDependents yourself

[10:06:55 CDT(-0500)] <anastasiac> we used to do that before IoC

[10:07:18 CDT(-0500)] <Justin_o> anastasiac: but that would mean that my parent component couldn't be autoInit either?

[10:07:32 CDT(-0500)] <anastasiac> ah, hum

[10:08:24 CDT(-0500)] <anastasiac> maybe you could call iniDepenents in one of the lifecycle functions, Justin_o - the pre- or post- or final - whichever corresponds most closely and appropriately with when subcomponents would be initialized

[10:08:47 CDT(-0500)] <Justin_o> anastasiac: okay.. i'll try that.. thanks

[10:19:56 CDT(-0500)] <Justin_o> anastasiac: looks like it's a call to initSubcomponent that i would need to make, but i would need to change my defaults. Also seems like this just won't work in my use case since the renderer is destroying it's container.. so i guess i'll have to think of something else. since at least the proto style of component trees doesn't seem to support non-autoInit components either

[10:20:36 CDT(-0500)] <anastasiac> ah, interesting

[10:34:19 CDT(-0500)] <jessm> fluid-everyone: standup?

[10:50:39 CDT(-0500)] <Justin_o> Bosmon: just wanted to check with you that in the proto style component trees can't handle non-autoInit components as decorators

[10:52:46 CDT(-0500)] <Bosmon> Justin_o - actually there's not a requirement that a decorator even represents at component at all

[10:52:52 CDT(-0500)] <Bosmon> a component

[10:53:16 CDT(-0500)] <Bosmon> Although naturally it is preferable that it does

[10:53:17 CDT(-0500)] <Justin_o> Bosmon: interesting… so i'm getting an object passed in instead of container

[10:53:21 CDT(-0500)] <Bosmon> What is your use case here?

[10:54:03 CDT(-0500)] <Justin_o> Bosmon: i'm trying to use the fluid.tooltip in decapod

[10:54:38 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/webapp/components/tooltip/js/Tooltip.js

[10:54:55 CDT(-0500)] <Justin_o> Bosmon: i had the same issue when i tried to use it in the components block of my decapod component

[10:55:06 CDT(-0500)] <Bosmon> I see... a venerable and ancient component

[10:55:24 CDT(-0500)] <Bosmon> In theory it should work fine

[10:55:43 CDT(-0500)] <Bosmon> But I guess the default grade is that of "littleComponent"....

[10:56:14 CDT(-0500)] <Justin_o> Bosmon: right.. the problem is not that it isn't autoInited, but that it isn't graded

[10:56:32 CDT(-0500)] <Bosmon> Yes

[10:56:43 CDT(-0500)] <Bosmon> You might just consider submitting a framework fix for that

[10:57:18 CDT(-0500)] <Bosmon> There is some evidence to suggest also, that if you issued a demands block for it that suggested that the component took 2 arguments, you might be able to get it to work....

[10:57:22 CDT(-0500)] <Bosmon> But that looks rather messy

[10:58:11 CDT(-0500)] <Justin_o> Bosmon: interesting… i suppose i could also just rewrite Tooltip.js to be graded.

[10:58:19 CDT(-0500)] <Justin_o> Bosmon: what would you suggest as the best approach

[10:58:35 CDT(-0500)] <Bosmon> We may as well insert grades into every view component in the framework in the same patch

[10:58:39 CDT(-0500)] <Bosmon> It is "no skin off our nose"

[10:58:55 CDT(-0500)] <Bosmon> We quite trust grades now, I think... in many ways despite being newer, they work a lot better than demands blocks

[11:00:33 CDT(-0500)] <Bosmon> I think we should even prepare for it to be an error to issue any component without a grade, in the quite near future

[11:00:42 CDT(-0500)] <Bosmon> Just as soon as we have fixed up all the ones in the framework

[11:00:47 CDT(-0500)] <Justin_o> Bosmon:

[11:00:55 CDT(-0500)] <Justin_o> Bosmon: yes. that makes sense

[11:01:18 CDT(-0500)] <Justin_o> Bosmon: so to be clear, you think we should go through all of our components in Infusion and make them graded.

[11:01:24 CDT(-0500)] <Bosmon> Justin_o - yes, i think so

[11:02:19 CDT(-0500)] <Justin_o> Bosmon: i guess if i don't make them autoInit it should just be a matter of adding gradeNames: … to the defaults

[11:02:27 CDT(-0500)] <Bosmon> Justin_o - that's right

[11:02:32 CDT(-0500)] <Bosmon> It should be a relatively harmless change

[11:02:39 CDT(-0500)] <Bosmon> No implementation code needs to be touched

[11:03:04 CDT(-0500)] <Justin_o> Bosmon: sounds good.. i'll write up a jira and get to that.. mind if i pass it off to you for review afterwards

[11:03:10 CDT(-0500)] <Bosmon> The relevant grade-guessing code is in lines 376-384 in FluidIoC.js

[11:03:18 CDT(-0500)] <Bosmon> As you can see, it is set up to guess wrong quite a lot of the time

[11:03:25 CDT(-0500)] <Bosmon> Justin_o - I'd love to review it

[11:05:40 CDT(-0500)] <Justin_o> Bosmon: thanks

[11:19:42 CDT(-0500)] <Justin_o> fluid-everyone: Just noticed that the imageReorderer tests are failing.. any ideas what might have happened?

[11:19:42 CDT(-0500)] <Justin_o> http://build.fluidproject.org/infusion/tests/component-tests/reorderer/html/ImageReorderer-test.html

[11:19:49 CDT(-0500)] <colinclark> eek

[11:20:27 CDT(-0500)] <Bosmon> That's pretty bad

[11:20:29 CDT(-0500)] <Justin_o> same with the reordered list tests http://build.fluidproject.org/infusion/tests/component-tests/reorderer/html/ReorderList-test.html

[11:20:55 CDT(-0500)] <Bosmon> My first thought was that my jquery upgrade is somehow to blame

[11:21:00 CDT(-0500)] <Bosmon> Although we did run those tests

[11:21:21 CDT(-0500)] <colinclark> I was thinking we might want to organize an Infusion mini-sprint

[11:21:23 CDT(-0500)] <colinclark> for a day or so

[11:21:27 CDT(-0500)] <Bosmon> I guess the good news is that they fail the same way cross-browser

[11:21:27 CDT(-0500)] <colinclark> to fix all these little things

[11:21:29 CDT(-0500)] <colinclark> and do some testing

[11:21:36 CDT(-0500)] <colinclark> the Builder is broken as well, which is a drag

[11:21:37 CDT(-0500)] <anastasiac> the layout reordered demo seems fine

[11:21:39 CDT(-0500)] <Bosmon> But still, the scale of the failure is quite startling

[11:32:30 CDT(-0500)] <colinclark> Justin_o: Do you think it would be reasonable to organize some kind of small day-long "Infusion tidy up" sprint in the next week or two?

[11:34:13 CDT(-0500)] <Bosmon> Justin_o - looks like the failure is due to the failure of our focusLightbox() function

[11:36:58 CDT(-0500)] <Justin_o> colinclark: that might be a good idea.. i guess we might need to collect a bunch of issues first though

[11:37:06 CDT(-0500)] <colinclark> Yeah, that makes sense

[11:37:35 CDT(-0500)] <Bosmon> It looks like this was done as a result of my fix for FLUID-4684

[11:38:09 CDT(-0500)] <Bosmon> Which is odd, because the purpose of the fix was to make the test cases pass again.....

[11:38:59 CDT(-0500)] <Justin_o> Bosmon: that seems strange.. these must have been run if that was the purpose of the fix

[11:39:34 CDT(-0500)] <Bosmon> Well, this is odd

[11:39:40 CDT(-0500)] <Bosmon> Reverting the change doesn't make them pass again.....

[11:58:54 CDT(-0500)] <Bosmon> The plot thickens... there seems to be something peculiarly wrong with the selectables plugin

[11:59:00 CDT(-0500)] <Bosmon> In that nothing seems to ever call "refresh" on it

[12:01:44 CDT(-0500)] <Justin_o> Bosmon: to distract you a bit, what grade would a component like this get https://github.com/fluid-project/infusion/blob/master/src/webapp/components/pager/js/Pager.js#L163

[12:02:06 CDT(-0500)] <Bosmon> No grade there

[12:02:25 CDT(-0500)] <Bosmon> That thing is something bizarre and malign : P

[12:02:30 CDT(-0500)] <Bosmon> And gets everything it deserves from the IoC system

[12:02:38 CDT(-0500)] <Bosmon> Anyway, it is never constructed via IoC

[12:02:44 CDT(-0500)] <Bosmon> You only need look at top-level Infusion components

[12:02:52 CDT(-0500)] <Justin_o> Bosmon: okay…

[12:02:55 CDT(-0500)] <Bosmon> So it seems we NEVER called "refresh" on the selectables

[12:03:05 CDT(-0500)] <Bosmon> This is rapidly getting into the "how did this ever work" territory....

[12:03:43 CDT(-0500)] <Bosmon> I'm wondering if my linting fix is involved somehow ....

[12:03:50 CDT(-0500)] <Bosmon> Somehow the keyboard-a11y tests pass by themselves

[12:06:35 CDT(-0500)] <Bosmon> Ok, nothing to do with that!

[12:06:46 CDT(-0500)] <Bosmon> Somehow, all the "movables" in the ImageReorderer test have the wrong CSS class on them

[12:07:01 CDT(-0500)] <Bosmon> .flc-reorderer-movable-default, rather than .flc-reorderer-movable

[12:08:45 CDT(-0500)] <Bosmon> Actually "fl-reorderer-movable-default"

[12:08:59 CDT(-0500)] <Bosmon> This name appears in ImageReordererTestConstants.js, but is never used..........

[12:18:20 CDT(-0500)] <Bosmon> Good grief

[12:18:25 CDT(-0500)] <Bosmon> It's a failure to do with defaults in graded options

[12:18:37 CDT(-0500)] <Bosmon> But I wonder when on earth it could have occurred

[12:19:46 CDT(-0500)] <Bosmon> I think I know!

[12:19:54 CDT(-0500)] <Bosmon> It was caused by the merge of ModelTransformations

[12:20:08 CDT(-0500)] <Bosmon> colinclark - remember that thing you queried... about the change in strategy for mergePolicies....

[12:20:24 CDT(-0500)] <colinclark> ?!

[12:20:51 CDT(-0500)] <colinclark> You mean when I was reviewing the latest version of ModelTransformations?

[12:20:56 CDT(-0500)] <Bosmon> Yes, exactly

[12:21:04 CDT(-0500)] <colinclark> Damn, I pushed failing unit tests

[12:21:11 CDT(-0500)] <Bosmon> You did!

[12:21:14 CDT(-0500)] <Bosmon> Yes...

[12:21:25 CDT(-0500)] <Bosmon> Although it would be hard to guess that there would be a failure so far away

[12:21:34 CDT(-0500)] <Bosmon> My work on "running all unit tests" becomes doubly as urgent....

[12:21:54 CDT(-0500)] <colinclark> Yeah, well

[12:21:59 CDT(-0500)] <colinclark> It still points out that I suck

[12:22:14 CDT(-0500)] <colinclark> There's no way anyone should be pushing anything to Infusion master without running the full test suite

[12:22:18 CDT(-0500)] <Bosmon> Actually the failure is in exactly the same bit of dodgy code I commented on to anastasiac in FLUID-4725

[12:22:19 CDT(-0500)] <colinclark> it's really not that hard to do

[12:22:36 CDT(-0500)] <colinclark> Literally the exact same code?

[12:22:49 CDT(-0500)] <colinclark> i.e. the improperly namespaced defaults?

[12:22:52 CDT(-0500)] <colinclark> in InlineEdit?

[12:22:52 CDT(-0500)] <Bosmon> No

[12:23:02 CDT(-0500)] <Bosmon> I JIRAed the problem separately as http://issues.fluidproject.org/browse/FLUID-4733

[12:23:05 CDT(-0500)] <Bosmon> Which is pretty ironic

[12:23:11 CDT(-0500)] <Bosmon> Given at the time I wrote this JIRA, this code had already failed

[12:23:17 CDT(-0500)] <Bosmon> But I highlighted it as an "implementation risk".....

[12:23:21 CDT(-0500)] <colinclark> oh this one

[12:23:22 CDT(-0500)] <colinclark> yes

[12:23:45 CDT(-0500)] <Bosmon> And the failure is in literally the exact part of the Reorderer's configuration that I quote here : P

[12:24:00 CDT(-0500)] <colinclark> Justin_o: I'm sorry for this, King.

[12:24:41 CDT(-0500)] <colinclark> Bosmon: You don't say specifically in FLUID-4733 how we might deal with this issue prior to tackling the much larger issue of FLUID-4392

[12:24:50 CDT(-0500)] <Bosmon> colinclark I didn't know

[12:24:55 CDT(-0500)] <Bosmon> er, I didn't, no

[12:24:57 CDT(-0500)] <Bosmon> hahaha

[12:24:59 CDT(-0500)] <colinclark>

[12:25:15 CDT(-0500)] <colinclark> Is it just a matter of rewriting the Reorderer's merge policy block somehow?

[12:25:15 CDT(-0500)] <Bosmon> But I guess also I didn't have a specific idea, beyond recognising that this code was inadequate

[12:25:30 CDT(-0500)] <Bosmon> Well, not really.... we need this policy to be able to work again

[12:25:38 CDT(-0500)] <Bosmon> And right now the mechanism for this is now broken

[12:25:40 CDT(-0500)] <colinclark> That's what I imagined, yes

[12:25:46 CDT(-0500)] <Bosmon> Just as well that anastasiac didn't yet take my advice on FLUID-4725

[12:26:09 CDT(-0500)] <Bosmon> This merge policy implementation was made right at the dawn of time

[12:26:16 CDT(-0500)] <Bosmon> Probably around the Infusion 0.6 mark

[12:26:46 CDT(-0500)] <Bosmon> Given that the only user of it is the Reorderer, and we have already decided that it is conceptually as well as implementationally broken, it might be a good time to rethink it

[12:27:30 CDT(-0500)] <Bosmon> Let's see for a start if we have ever documented it

[12:27:54 CDT(-0500)] <Bosmon> http://wiki.fluidproject.org/display/fluid/Options+Merging+for+Infusion+Components#OptionsMergingforInfusionComponents-StructureoftheMergePolicyObject

[12:27:56 CDT(-0500)] <Bosmon> Looks like we have

[12:28:02 CDT(-0500)] <Bosmon> It is listed under "any other string value"

[12:28:15 CDT(-0500)] <Bosmon> I guess this, for the time being, commits us to fixing it

[12:28:15 CDT(-0500)] <colinclark> To what extent can we fully rethink it without implementing FLUID-4392?

[12:28:29 CDT(-0500)] <colinclark> aha, backwards compatibility in this case

[12:28:44 CDT(-0500)] <Bosmon> Although it is rather crappy that this prevents people from using options with the names of "replace", "preserve" etc.

[12:28:53 CDT(-0500)] <Bosmon> They're unlikely to, but it is an egregrious fault

[12:29:03 CDT(-0500)] <colinclark> it's pretty clear that our contract is EL paths on the left

[12:29:08 CDT(-0500)] <colinclark> and the potential for EL paths on the right

[12:29:28 CDT(-0500)] <colinclark> alongside a few special names or a function

[12:30:14 CDT(-0500)] <Bosmon> I guess the KING would not permit us to reimplement this... but I guess we could implement an extension

[12:30:21 CDT(-0500)] <Bosmon> This stuff hugely predates model transformations, of course

[12:30:29 CDT(-0500)] <Bosmon> But it should really work in a way which is consistent with it

[12:30:46 CDT(-0500)] <Bosmon> The trouble is, the most frequently used merge policies are the ones which do NOT have EL paths on the RHS

[12:31:01 CDT(-0500)] <Bosmon> But being consistent with model transformations would imply it is those ones which have to become more verbose

[12:34:52 CDT(-0500)] <colinclark> yes, I see what you mean

[12:39:34 CDT(-0500)] <Bosmon> Justin_o, colinclark: http://issues.fluidproject.org/browse/FLUID-4736

[12:40:13 CDT(-0500)] <colinclark> Thanks, Bosmon

[12:40:19 CDT(-0500)] <colinclark> So what do you think our next step should be?

[12:40:35 CDT(-0500)] <Justin_o> Bosmon: thanks for filing that

[12:40:45 CDT(-0500)] <Bosmon> Justin_o, avtar - I'm wondering what the status of our testswarm installation is?

[12:40:56 CDT(-0500)] <Bosmon> It would be good to have a system that could alert us to problems like this earlier on

[12:41:01 CDT(-0500)] <colinclark> it really would

[12:41:07 CDT(-0500)] <Bosmon> colinclark - I will make a straightforward fix for the issue

[12:41:12 CDT(-0500)] <Bosmon> After thinking about it in the shower for a bit

[12:41:20 CDT(-0500)] <colinclark> Huge +1 for me on a reliable Testswarm configuration

[12:41:26 CDT(-0500)] <Justin_o> Bosmon: that's something that the jQuery testing team is working on.. there new strategy involves using jenkins to manage testswarm

[12:41:30 CDT(-0500)] <Bosmon> This last piece of mergeImpl probably just needs to be split off into a separate function

[12:41:32 CDT(-0500)] <colinclark> Bosmon: Do you know what the straightforward fix is?

[12:41:39 CDT(-0500)] <Bosmon> It was always a bit of an eyesore sitting there at the top level impl

[12:41:48 CDT(-0500)] <colinclark> Justin_o: I guess I'd like to get a better sense of what the needs are

[12:41:52 CDT(-0500)] <colinclark> So, put another way:

[12:42:00 CDT(-0500)] <colinclark> 1. What is the current status of our Testswarm instance?

[12:42:09 CDT(-0500)] <colinclark> 2. What prevents Testswarm from being used reliably?

[12:42:23 CDT(-0500)] <colinclark> 3. What sort of things do a) Avtar and b) we need to do to make it all happen?

[12:42:37 CDT(-0500)] <colinclark> I imagine you probably know the most about this issue, Justin_o

[12:43:01 CDT(-0500)] <colinclark> (and while you think about it, I'm going to sneak off quickly for a sandwich)

[12:43:10 CDT(-0500)] <Justin_o> colinclark: okay

[12:43:20 CDT(-0500)] <avtar> hi all

[12:44:07 CDT(-0500)] <Justin_o> colinclark: well we would need to have a consistent supply of machines/vms to run against it.. in the past i'd have to restart the browsers every so often as they'd start to choke after a while.. probably a memory issue.. but not sure..

[12:44:26 CDT(-0500)] <Justin_o> colinclark: we should probably also upgrade to the latest version and get an jenkins instance up and running

[12:44:41 CDT(-0500)] <avtar> Justin_o: how many VMs would you estimate are required?

[12:46:27 CDT(-0500)] <Justin_o> avtar: we'd need to be able to cover all of the current desktop browsers listed here

[12:46:28 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Prior+Browser+Support

[12:47:10 CDT(-0500)] <Justin_o> although this chart would need to but updated for 1.5

[12:47:53 CDT(-0500)] <Justin_o> but anyways.. probably about 6 vm's/machines including something for mac os

[12:47:58 CDT(-0500)] <Justin_o> avtar: ^

[12:50:10 CDT(-0500)] <Justin_o> avtar: for jQuery they are using http://www.browserstack.com/ for their test environments.. not sure if there is something like that for us to use

[12:52:35 CDT(-0500)] <avtar> hrmm

[12:53:06 CDT(-0500)] <avtar> a os x vm running on kvm is something i'll have to look into

[12:53:57 CDT(-0500)] <Justin_o> avtar: okay, thanks

[12:55:22 CDT(-0500)] <avtar> brb, need to find food

[12:56:04 CDT(-0500)] <Justin_o> okay

[12:59:15 CDT(-0500)] <Bosmon> I guess it is actually illegal to automatically try to create new MacOS VMs : P

[13:02:18 CDT(-0500)] <Justin_o> Bosmon: they started to let you do this in Lion, provided both the host and VM were running Lion.. i suppose now that Mountain Lion is out this will carry forward

[13:02:33 CDT(-0500)] <Justin_o> Bosmon: by the way here's my pull request https://github.com/fluid-project/infusion/pull/228

[13:02:38 CDT(-0500)] <Bosmon> Thanks, Justin_o

[13:02:46 CDT(-0500)] <Justin_o> although I'm a bit unsure of the non-standard components

[13:03:55 CDT(-0500)] <Bosmon> Well, you need to verify 2 things

[13:04:03 CDT(-0500)] <Bosmon> It's not just enough to look at the initialisation function which is used

[13:04:08 CDT(-0500)] <Bosmon> The component also has to have the standard signature

[13:04:18 CDT(-0500)] <Bosmon> So, for example, "undoDecorator" doesn't count as a genuine littleComponent

[13:04:27 CDT(-0500)] <Bosmon> Since it has the options argument in the wrong place

[13:04:53 CDT(-0500)] <Bosmon> The main use we are making of the grade structure is actually to ensure that each component is supplied with an accurate "argMap"

[13:05:06 CDT(-0500)] <Bosmon> So actually that is more essential to check than which init function is used

[13:08:36 CDT(-0500)] <Justin_o> Bosmon: makes sense.. i was a bit confused by that one, because the function is called fluid.undoDecorator, but the defaults and init are against "undo"

[13:08:47 CDT(-0500)] <Bosmon> That is a bug

[13:09:27 CDT(-0500)] <Bosmon> Similar to the one raised against InlineEdit

[13:09:44 CDT(-0500)] <colinclark> avtar, Justin_o: Circling back to Testswarm now that I'm back, I guess realistically we need an OS X box serving as a "constant client" to Testswarm still.

[13:09:44 CDT(-0500)] <Justin_o> okay.. so i'll change that one up.. i think i looked at the signature for the rest, but i'll double check

[13:09:58 CDT(-0500)] <colinclark> At the moment, you have a box under your desk that sort of serves this purpose, is that right, Justin_o?

[13:11:11 CDT(-0500)] <Justin_o> colinclark: yep, that's correct.. although i only had a trial license for the virtualization software there.. i had been waiting for that site license to come through, but looks like that isn't possible anymore

[13:11:53 CDT(-0500)] <colinclark> Will VirtualBox work?

[13:24:04 CDT(-0500)] <Justin_o> colinclark: hard to tell.. i just upgraded my virutalbox and checked.. it only have options for mac os server, not sure if that will let you install the regular mac os or not… although there are a bunch of hits on google for how to get lion running on windows so i guess it should work one way or another… although i'd like to know if it was officially supported or not

[13:28:00 CDT(-0500)] <colinclark> Justin_o: Worst case, we'd be looking at 1 license of VMWare Fusion?

[13:28:14 CDT(-0500)] <Justin_o> colinclark: yep. that sounds about right

[13:28:22 CDT(-0500)] <colinclark> I think we can manage that, one way or another

[13:28:35 CDT(-0500)] <colinclark> Worst case, I'll give up my license for the good of the tests

[13:29:20 CDT(-0500)] <Justin_o> colinclark: okay.. so in general we should have the vm support / machines

[13:29:30 CDT(-0500)] <colinclark> cool

[13:46:43 CDT(-0500)] <Justin_o> Bosmon: i've updated the pull request, i've removed the change to undo.js

[14:18:22 CDT(-0500)] <Justin_o> Bosmon: i have a question about creating a component dynamically..

[14:18:37 CDT(-0500)] <Bosmon> Hi Justin_o - Just reviewing your request now

[14:18:44 CDT(-0500)] <Justin_o> Bosmon: thanks..

[14:18:45 CDT(-0500)] <Bosmon> How come it still only consists of one commit?

[14:18:52 CDT(-0500)] <Bosmon> Did you do some kind of github magic? : P

[14:19:59 CDT(-0500)] <Justin_o> Bosmon: yes.. i figured that it was a small enough change that i'd finally have a chance to try out using git reset to compact several commits down to one.. it was in that git article you sent out to the list a while ago

[14:20:14 CDT(-0500)] <Bosmon> fascinating

[14:20:20 CDT(-0500)] <Bosmon> But how did you fool the server?

[14:20:34 CDT(-0500)] <Bosmon> Given you had presumably already issued the pull request once with 1 commit

[14:21:08 CDT(-0500)] <Justin_o> Bosmon: yes.. well.. github is smart enough to not allow you to push that kind of thing back up.. since it will change what's there..

[14:21:35 CDT(-0500)] <Justin_o> Bosmon: but they let you delete those branches.. and when you put one back up with the same name.. the pull request doesn't care

[14:21:44 CDT(-0500)] <Bosmon> Oh, fascinating....

[14:22:00 CDT(-0500)] <Bosmon> I wonder what a pull request looks like that has had its branch deleted and not recreated

[14:22:13 CDT(-0500)] <Justin_o> Bosmon: i should have checked that

[14:22:37 CDT(-0500)] <Justin_o> i did the change pretty quick though.. since i had it all sorted out on my machine before changing it in github

[14:23:11 CDT(-0500)] <Bosmon> ok

[14:23:15 CDT(-0500)] <Bosmon> Your pull request looks good

[14:23:27 CDT(-0500)] <Bosmon> As far as I can see, you have not broken any more of the tests, in addition to the ones that are already broken : P

[14:24:33 CDT(-0500)] <Justin_o> Bosmon: that's good.. i tried them all too.. hopefully there's nothing hidden in those reorder ones

[14:25:31 CDT(-0500)] <Bosmon> Wow.... the pull request page updates by AJAX...

[14:25:37 CDT(-0500)] <Bosmon> It already knows that it is closed

[14:26:38 CDT(-0500)] <Justin_o> Bosmon: i think that was a pretty recent feature addition..

[14:27:19 CDT(-0500)] <Justin_o> Bosmon: the other thing i just noticed today, not sure how long it's been there, is that they make it easier for you to diff your branches.. new ui element there beside pull request

[14:27:36 CDT(-0500)] <Bosmon> Oh yes, I need to remember to try to use that

[14:27:41 CDT(-0500)] <Bosmon> You were going to ask about dynamic components?

[14:28:37 CDT(-0500)] <Justin_o> Bosmon: oh yes.. you might have some thoughts on this.. so what i need to do is add a tooltip that is basically an error message if a user enters something invalid into a text input… there are three of these in the form

[14:28:47 CDT(-0500)] <Justin_o> http://issues.fluidproject.org/secure/attachment/12577/Decapod+0.6+Export-14.png

[14:28:55 CDT(-0500)] <Justin_o> see the bottom

[14:29:00 CDT(-0500)] <Bosmon> Yes

[14:29:10 CDT(-0500)] <Bosmon> But I presume that no more than one of them may be visible at a time

[14:29:15 CDT(-0500)] <Bosmon> I suggest you use the same component for each one

[14:29:23 CDT(-0500)] <Bosmon> Tooltips are a classic "flyweight" use case

[14:29:48 CDT(-0500)] <Bosmon> If we could have our way, we would arrange it so that there is no more than one of them on an entire HTML page : P

[14:30:22 CDT(-0500)] <Justin_o> Bosmon: yes.. i think i remember you saying that when we were working on this for pager.. although in the end i think it creates a new one for each..

[14:30:27 CDT(-0500)] <Justin_o> could be wrong though…

[14:30:46 CDT(-0500)] <Bosmon> Yes... and a result of this, I suspect still creates a huge amount of DOM garbage

[14:30:52 CDT(-0500)] <Justin_o> yep

[14:30:58 CDT(-0500)] <Bosmon> As far as I'm aware, we never resolved the issue of it failing to clean up its DOM droppings

[14:31:29 CDT(-0500)] <Justin_o> Bosmon: we do destroy it on re-render, but don't know if that removes the dom elements it creates

[14:32:14 CDT(-0500)] <Justin_o> Bosmon: so what i was hoping to do would be to create the tooltip only when an invalid entry is made

[14:32:36 CDT(-0500)] <Bosmon> You can register it as a "createOnEvent" subcomponent

[14:33:03 CDT(-0500)] <Bosmon> But it might be simpler just to create it on startup

[14:33:07 CDT(-0500)] <Justin_o> Bosmon: also the tooltip should be removed if a valid entry is now made

[14:33:21 CDT(-0500)] <Bosmon> removed === hidden

[14:34:26 CDT(-0500)] <Justin_o> Bosmon: i suppose i could do that.. the tooltip does support destruction and disabling… but was wondering also if another validation error event is thrown will another component be created automatically by the createOnEvent or does that only ever happen once?

[14:35:08 CDT(-0500)] <Bosmon> It will try to create it again

[14:35:18 CDT(-0500)] <Bosmon> Hence it being preferable to create it on startup, if you only ever want one

[14:36:38 CDT(-0500)] <Justin_o> Bosmon: hmm.. okay.. so the tooltip wrapper component adds it to it's container..

[14:37:01 CDT(-0500)] <Justin_o> and position as well as hover events are based on this as well.

[14:37:07 CDT(-0500)] <Justin_o> any thoughts on how to get around that

[14:37:25 CDT(-0500)] <Justin_o> i wouldn't want to hover over a different input and get the error message

[14:38:36 CDT(-0500)] <Bosmon> Justin_o - the wrapper should take care of this issue

[14:38:43 CDT(-0500)] <Bosmon> If it doesn't, it would be a great time to make a fix to it

[14:38:50 CDT(-0500)] <Bosmon> So we don't suffer the nonsense we did with the pager

[14:39:17 CDT(-0500)] <Justin_o>

[14:39:35 CDT(-0500)] <Justin_o> Bosmon: makes sense.. i wonder if jQuery UI 1.9 has a better tooltip in generatl

[14:39:39 CDT(-0500)] <Justin_o> general

[14:40:40 CDT(-0500)] <Bosmon> It's worth making a quick investigation

[14:41:09 CDT(-0500)] <Justin_o> Bosmon: here's the code for it https://github.com/jquery/jquery-ui/blob/1.9.0-beta.1/ui/jquery.ui.tooltip.js

[14:41:46 CDT(-0500)] <Justin_o> Bosmon: looks like they've update the position api in 1.9 http://forum.jquery.com/topic/position-api-redesign

[14:41:54 CDT(-0500)] <Justin_o> which is probably a welcome change in itself

[14:42:04 CDT(-0500)] <Bosmon> Not that again

[14:42:14 CDT(-0500)] <Bosmon> Hopefully it actually works now

[14:42:26 CDT(-0500)] <Bosmon> Although I guess we have also hopefully learned our lesson not to use such things in future

[14:42:30 CDT(-0500)] <Bosmon> Except in real emergencies

[14:42:33 CDT(-0500)] <Bosmon> Like tooltips : p

[14:45:08 CDT(-0500)] <Justin_o> Bosmon: yah.. it was pretty awful.. hopefully it works now… i tried adding the tooltip now, when the component was hidden.. and the tooltip remained about 2000px offscreen..

[14:45:57 CDT(-0500)] <Bosmon> This was probably the kind of issue that intimidated us back around the time of the pager

[14:46:04 CDT(-0500)] <Bosmon> I suggest we try to plough through them manfully this time

[14:48:08 CDT(-0500)] <Bosmon> We've had enough second-rate code committed to the framework to last us for the time being : P

[14:49:00 CDT(-0500)] <Justin_o> Bosmon: okay.. i might give this new tooltip a quick look and see if it actually works with our version of jQuery UI and then look to see what i can do with our tooltip wrapper

[14:51:40 CDT(-0500)] <Bosmon> Justin_o - surely we're not behind again already?

[14:52:58 CDT(-0500)] <Justin_o> Bosmon: well technically yes … http://blog.jqueryui.com/2012/07/jquery-ui-1-8-22/

[14:53:30 CDT(-0500)] <Justin_o> Bosmon: but the tooltip is from the 1.9 beta, the tooltip we were using was from an earlier pre-release of 1.9

[14:54:57 CDT(-0500)] <Bosmon> isn't there a version of the tooltip certified for use with a release version of UI?

[15:03:51 CDT(-0500)] <Justin_o> Bosmon: here's the source for the latest jQuery UI https://github.com/jquery/jquery-ui/tree/1.8.22/ui

[15:04:07 CDT(-0500)] <Justin_o> no tooltip there

[15:09:36 CDT(-0500)] <Justin_o> i think it's a new to 1.9

[18:37:06 CDT(-0500)] <travis_84> Hey Bosmon

[18:40:39 CDT(-0500)] <Bosmon> hi there travis_84!

[18:40:43 CDT(-0500)] <Bosmon> How's it going?

[18:43:48 CDT(-0500)] <travis_84> good. got your email. I had checked in IRC a few times the last two weeks, but michelled told me you were gone or something. which is why I started emailing...

[18:45:47 CDT(-0500)] <Bosmon> Yes... I had been hoping that the mentorship team would be a bit more loosely defined, but it is seeming that in practice it consists of just me : P

[18:45:55 CDT(-0500)] <Bosmon> Sorry

[18:47:11 CDT(-0500)] <Bosmon> But I am promising to do better - hence my proposal re regular meetings at least

[18:47:16 CDT(-0500)] <Bosmon> Do those times make sense?

[18:48:38 CDT(-0500)] <travis_84> Friday won't work... I moved my weekly medical appt to that day. Thurs. work?

[18:49:04 CDT(-0500)] <travis_84> 3pm MST is 2pm PST right?

[18:49:09 CDT(-0500)] <Bosmon> Yup

[18:49:12 CDT(-0500)] <Bosmon> Thursday is good

[18:49:16 CDT(-0500)] <Bosmon> And how about our other day?

[18:50:07 CDT(-0500)] <travis_84> Tuesday is fine

[18:50:23 CDT(-0500)] <Bosmon> Cool

[18:50:32 CDT(-0500)] <Bosmon> So, what problems are you grappling with currently?

[18:50:43 CDT(-0500)] <Bosmon> And I guess we should think about this issue of a slightly more detailed roadmap

[18:50:49 CDT(-0500)] <Bosmon> given we will be at the end of the project before too long

[18:51:51 CDT(-0500)] <travis_84> GSoC at least... Hopefully we won't end there?

[18:52:00 CDT(-0500)] <Bosmon> I hope not

[18:52:06 CDT(-0500)] <Bosmon> But I believe they will actually need to see something...

[18:53:55 CDT(-0500)] <travis_84> I updated git today with one of my attempts to output the code of the JSON doc object array correctly... sadly the nesting is causing an issue with the method I am using.

[18:54:04 CDT(-0500)] <Bosmon> Ok, let me take a look

[18:55:04 CDT(-0500)] <Bosmon> Ok, looks like you have a hard-coded grammar for the time being

[18:55:21 CDT(-0500)] <Bosmon> But that you have made some headway in factoring it out into different groups

[18:56:01 CDT(-0500)] <Bosmon> Which part should I look at to see the problematic nesting issue?

[18:56:32 CDT(-0500)] <Bosmon> I notice you have 2 nested $.each loops around line 186

[18:57:02 CDT(-0500)] <Bosmon> Which is sort of bearable, but if it gets any worse, you may want to think of a different approach...

[18:57:13 CDT(-0500)] <Bosmon> I notice that both of them seem to be iterating over the same collection....

[18:57:50 CDT(-0500)] <Bosmon> I think things have easily got to the level of complexity now that you would want to start thinking about writing some automated test cases

[18:58:02 CDT(-0500)] <Bosmon> Otherwise you are rapidly going to start losing track of what functionality you have successfully implemented

[19:03:12 CDT(-0500)] <travis_84> yes I can speak a full "unending" command, I put the JSGF on the backburner because the amount of words is secondary to having proper output. As for the $.each, I feel this works for the "template" objDocument that is there but once you add another array object to it, the output of the new item in the textarea is added after the end of </html> rather then between <body/>

[19:04:13 CDT(-0500)] <Bosmon> What do you mean by "unending"?

[19:04:40 CDT(-0500)] <travis_84> I am wondering if there is another way of outputting the text? I know the implementation of the parent -> hasChild data is useful

[19:07:22 CDT(-0500)] <Bosmon> Yes - what ideas do you have for moving or selecting the insertion point?

[19:08:49 CDT(-0500)] <Bosmon> But, can you tell me more about your immediate problem with the nesting?

[19:12:06 CDT(-0500)] <colinclark> hey thealphanerd, you didn't end up going to the a11y "drink up" tonight?

[19:12:22 CDT(-0500)] <travis_84> unending meaning that where it says public <top> is the command template of what is going to be said, a command like "insert", a element like "header", and the audit is for the location like "here" or a conjunction like "and". the text between the [...]* means it is optional and can be said zero or multiple times.. So theoretically we can speak "unending" commands like "insert header [and add ID][and select footer][with ID } "

[19:15:58 CDT(-0500)] <travis_84> do you get what I mean about "unending"

[19:16:09 CDT(-0500)] <travis_84> ?

[19:16:44 CDT(-0500)] <Bosmon> I think so.... it sounds like it means that the speech is governed by a single grammar without "restart points"?

[19:19:54 CDT(-0500)] <travis_84> the WAMI api says that if we had something like itterative set to true, the pattern set in the public <top> is how it would know when to

[19:20:12 CDT(-0500)] <travis_84> "settle" a sentence

[19:20:40 CDT(-0500)] <travis_84> or when a particular command ends

[19:22:21 CDT(-0500)] <travis_84> so what I did is reduce any action to its basic form; commands like insert . delete

[19:23:06 CDT(-0500)] <travis_84> and the element; tags , attr , etc.

[19:25:08 CDT(-0500)] <travis_84> it knows how to separate each command (or "settle") when ever it sees an audit word

[19:25:49 CDT(-0500)] <travis_84> I didn't know what else to call it : )

[19:26:34 CDT(-0500)] <Bosmon> That seems fine... sometimes one talks of "terminators"... like semicolons

[19:26:37 CDT(-0500)] <Bosmon> Of "end of productions"

[19:26:51 CDT(-0500)] <Bosmon> But - tell me about your problem

[19:29:57 CDT(-0500)] <travis_84> ok, so I am only working on "insert" right now, with header or footer as the usable tags

[19:30:16 CDT(-0500)] <Bosmon> Also - do you think it would be easier for us to have a voice call tomorrow, for our "first meeting"? : P

[19:30:44 CDT(-0500)] <travis_84> rather then a single "code" string being returned, I separated it into start and end strings

[19:31:29 CDT(-0500)] <travis_84> uh ya

[19:31:37 CDT(-0500)] <Bosmon> Where can I see the start and end?

[19:31:47 CDT(-0500)] <travis_84> it would go a lot faster

[19:31:54 CDT(-0500)] <Bosmon> Are they separated by these pipe characters | ?

[19:31:59 CDT(-0500)] <Bosmon> Ok

[19:32:02 CDT(-0500)] <Bosmon> Does Skype work for you?

[19:32:26 CDT(-0500)] <Bosmon> I seem to have you as a Skype contact already....

[19:32:27 CDT(-0500)] <travis_84> ya

[19:32:41 CDT(-0500)] <travis_84> you do

[19:32:43 CDT(-0500)] <Bosmon> But I don't think I've ever seen you online

[19:33:12 CDT(-0500)] <travis_84> no it was when irc hates me

[19:33:50 CDT(-0500)] <Bosmon> oh yes

[19:33:55 CDT(-0500)] <Bosmon> I remember that time

[19:33:55 CDT(-0500)] <travis_84> we txted through skype

[19:35:16 CDT(-0500)] <travis_84> go to line 155

[19:36:10 CDT(-0500)] <Bosmon> Oh yes, I see now

[19:36:13 CDT(-0500)] <Bosmon> codeStart and codeEnd

[19:36:23 CDT(-0500)] <travis_84> rather then going through all the html elements, I just changed a short list

[19:37:43 CDT(-0500)] <travis_84> so in processResults() line 216

[19:39:00 CDT(-0500)] <travis_84> it takes those two and sends it to outputToDoc()

[19:39:13 CDT(-0500)] <Bosmon> Yes

[19:39:26 CDT(-0500)] <Bosmon> I guess you need to build up a stronger system for talking about "places in the document"

[19:39:41 CDT(-0500)] <Bosmon> And I guess in practice, there might need to be at least 2 of them active at any time

[19:40:29 CDT(-0500)] <Bosmon> A plausible action by the user would be to "select place 1"... "select place 2".... and then, so long as they are compatible (in terms of nesting depth) they would then issue the "inert header" command which would put the codeStart and codeEnd at the respective places

[19:40:35 CDT(-0500)] <Bosmon> insert header

[19:41:24 CDT(-0500)] <Bosmon> So there needs to be some concept of at least two "cursors", rather than just necessarily outputing to the document end

[19:41:32 CDT(-0500)] <Bosmon> Does that sound like the thing you want to tackle next?

[19:41:38 CDT(-0500)] <Bosmon> Or do you have a further problem in the meantime?

[19:44:58 CDT(-0500)] <travis_84> no that sounds about right... I guess I am running to the scenario where it sees hasChild : true at the current pointer spot, and having it keep its current place but look for its children

[19:45:15 CDT(-0500)] <Bosmon> Ok

[19:45:22 CDT(-0500)] <Bosmon> And this will start to get you into the business of "selectors"

[19:45:24 CDT(-0500)] <travis_84> or should be the other way?

[19:45:35 CDT(-0500)] <Bosmon> Letting the user talk about a position in the document in terms of some particular language

[19:45:43 CDT(-0500)] <Bosmon> WHether this is the language of CSS selectors or something else

[19:46:07 CDT(-0500)] <Bosmon> "set cursor to "li"" or so

[19:46:19 CDT(-0500)] <Bosmon> Is something you imagine being a plausible command in the system

[19:46:48 CDT(-0500)] <Bosmon> I see you already have a "select" command

[19:47:14 CDT(-0500)] <Bosmon> But it doesn't look like it does anything yet?

[19:47:22 CDT(-0500)] <travis_84> well hold on

[19:51:26 CDT(-0500)] <travis_84> I don't want to confuse "user" selection with "system" selection, I am not saying "when the user says 'select header'" that can be solved (i think) when we can show it how to "select" things in the document as its outputting the text

[19:52:13 CDT(-0500)] <Bosmon> Ok - how do you distinguish user selection from system selection?

[19:55:27 CDT(-0500)] <travis_84> ok no you're right, I am confusing myself now.

[20:03:58 CDT(-0500)] <travis_84> ok so if you notice in the objDocument i have the parent set to the objID of the object I want it linked to

[20:04:34 CDT(-0500)] <thealphanerd> colinclark: I was there… just got home

[20:04:44 CDT(-0500)] <colinclark> how was it?

[20:04:49 CDT(-0500)] <thealphanerd> good times

[20:04:49 CDT(-0500)] <colinclark> sorry I couldn't make it

[20:04:52 CDT(-0500)] <thealphanerd> cheap drinks

[20:04:54 CDT(-0500)] <thealphanerd> good company

[20:04:55 CDT(-0500)] <colinclark> I was supposed to be sailing, but then it rained

[20:04:56 CDT(-0500)] <thealphanerd> chicken fingers

[20:04:56 CDT(-0500)] <colinclark> cool

[20:04:59 CDT(-0500)] <colinclark> how's Jennison?

[20:05:03 CDT(-0500)] <thealphanerd> he's doing well

[20:05:16 CDT(-0500)] <thealphanerd> he was mentioning something about korean bbq on friday

[20:05:20 CDT(-0500)] <colinclark> ooh

[20:05:27 CDT(-0500)] <colinclark> that sounds like fun

[20:05:28 CDT(-0500)] <thealphanerd> invite yourself

[20:05:32 CDT(-0500)] <colinclark> lol

[20:05:34 CDT(-0500)] <colinclark> I should!

[20:05:45 CDT(-0500)] <thealphanerd> so I got some more progress done

[20:05:50 CDT(-0500)] <colinclark> cool

[20:05:53 CDT(-0500)] <colinclark> I was just going to ask

[20:05:54 CDT(-0500)] <thealphanerd> the datgui elements are now infusion components

[20:06:20 CDT(-0500)] <thealphanerd> stil have to work out a bit of logic so that you can add and remove elements from the gui on the fly

[20:06:40 CDT(-0500)] <thealphanerd> and I'm playing with the polyphony stuff

[20:06:51 CDT(-0500)] <thealphanerd> still trying to work out the best way to do it

[20:07:03 CDT(-0500)] <colinclark> oh nice

[20:07:09 CDT(-0500)] <thealphanerd> with the latest flocking, am I able to update a synth with a complete model now

[20:07:11 CDT(-0500)] <thealphanerd> ?

[20:07:41 CDT(-0500)] <travis_84> Bosmon: want to save this for tomorrow?

[20:07:42 CDT(-0500)] <colinclark> yes

[20:07:47 CDT(-0500)] <Bosmon> travis_84 - sure

[20:07:48 CDT(-0500)] <colinclark> but let me make a new push shortly, thealphanerd

[20:07:53 CDT(-0500)] <colinclark> i have a big new fix

[20:07:58 CDT(-0500)] <thealphanerd> sweet

[20:08:07 CDT(-0500)] <thealphanerd> and I've been trying to figure out the aria stuff

[20:08:12 CDT(-0500)] <thealphanerd> been reading the w3 doc

[20:08:18 CDT(-0500)] <Bosmon> So, Skype at 3PM MST = 2pm PST?

[20:08:20 CDT(-0500)] <thealphanerd> and going through some slide shows

[20:08:28 CDT(-0500)] <Bosmon> Perhaps colinclark may be able to pop in too

[20:08:42 CDT(-0500)] <travis_84> Bosmon: yep

[20:08:48 CDT(-0500)] <thealphanerd> but I'm thinking that I need to sit down and learn about screen readers a bit more before I try and wrap my head around it 100%

[20:09:18 CDT(-0500)] <colinclark> one sec

[20:09:23 CDT(-0500)] <thealphanerd> kk

[20:09:24 CDT(-0500)] <colinclark> my sister is on the phone

[20:09:28 CDT(-0500)] <colinclark> telling me how much she loves cheese

[20:09:51 CDT(-0500)] <colinclark> bizarre

[20:10:13 CDT(-0500)] <Bosmon> cheese is great

[20:10:16 CDT(-0500)] <thealphanerd> colinclark: there's a great cheese vendor at my local farmers market

[20:10:20 CDT(-0500)] <Bosmon> I brought another 3kg with me from the UK this time

[20:10:23 CDT(-0500)] <thealphanerd> I'm not cray about it myself

[20:15:12 CDT(-0500)] <colinclark> i like cheese fairly well

[20:15:23 CDT(-0500)] <colinclark> it's just interesting how much she likes it

[20:15:31 CDT(-0500)] <colinclark> i guess i like wine equivalently

[20:16:15 CDT(-0500)] <colinclark> Bosmon: is your 3kgs a kind of British cheese?

[20:17:31 CDT(-0500)] <Bosmon> Well, some of it is Camembert : P

[20:17:36 CDT(-0500)] <Bosmon> The majority of it is CHEDDAR

[20:18:08 CDT(-0500)] <colinclark> FRENCH cheese!

[20:20:07 CDT(-0500)] <thealphanerd> lol

[20:20:19 CDT(-0500)] <Bosmon> Well, it may well be a French kind of cheese made in Britain

[20:20:21 CDT(-0500)] <Bosmon> Let me check....

[20:20:58 CDT(-0500)] <Bosmon> No, it clearly says MADE IN FRANCE USING MILK FROM FRANCE : P

[20:21:03 CDT(-0500)] <Bosmon> With somewhat unnecessary detail....

[20:21:28 CDT(-0500)] <thealphanerd> maybe to you

[20:27:39 CDT(-0500)] <colinclark>

[20:27:44 CDT(-0500)] <colinclark> Okay, my phone call is done

[20:27:50 CDT(-0500)] <colinclark> oddly it went from cheese to the new Yahoo! CEO

[20:27:57 CDT(-0500)] <colinclark> I think I'm tired about talking about CEOs in general

[20:28:08 CDT(-0500)] <colinclark> CEOs and "cool frameworks"

[20:28:23 CDT(-0500)] <colinclark> so, speaking of cool frameworks, nice work making some new Infusion components, thealphanerd

[20:28:33 CDT(-0500)] <colinclark> In terms of polyphony, I don't think it will be terribly difficult

[20:28:56 CDT(-0500)] <colinclark> And it will the be the feature that destroys your 8-bit competitor

[20:29:07 CDT(-0500)] <colinclark> despite his square waves

[20:31:57 CDT(-0500)] <colinclark> thealphanerd: In terms of being able to set multiple inputs at once, it landed in Flocking about the time I landed from Vienna

[20:32:07 CDT(-0500)] <colinclark> but a lot of that code was a bit, well, jet lagged

[20:32:28 CDT(-0500)] <colinclark> so I'm just about to push a substantial improvement to the whole process of setting and getting input values

[20:33:50 CDT(-0500)] <colinclark> thealphanerd: I was thinking that the thing you end up making to handle polyphony fits into a category of objects that exist only very tentatively in the architecture right now

[20:34:22 CDT(-0500)] <colinclark> Synths are a kind of object among several

[20:34:42 CDT(-0500)] <colinclark> I always imagined that you could create groups of synths, and then sent them input messages like an ordinary synth

[20:35:35 CDT(-0500)] <colinclark> but that the Group would automatically "multiplex" the changes (or is it "demultiplex", Bosmon?) to the Synths within the group

[20:35:47 CDT(-0500)] <colinclark> in your case, you've got a special kind of SynthGroup, or whatever it will be

[20:35:58 CDT(-0500)] <Bosmon> demultiplex, I imagine

[20:36:29 CDT(-0500)] <Bosmon> Who is the 8-bit competitour?

[20:36:42 CDT(-0500)] <colinclark> let me see if I have the link

[20:36:48 CDT(-0500)] <colinclark> Ah yes

[20:37:02 CDT(-0500)] <colinclark> The cleverly named "Qwerty Hancock"

[20:37:04 CDT(-0500)] <colinclark> http://stuartmemo.com/qwerty-hancock/

[20:37:21 CDT(-0500)] <Bosmon> Wow

[20:37:23 CDT(-0500)] <Bosmon> What a strange guy

[20:37:45 CDT(-0500)] <Bosmon> Also

[20:37:48 CDT(-0500)] <Bosmon> What a completely appalling sound!

[20:38:07 CDT(-0500)] <colinclark> I thought it was sort of funky

[20:38:11 CDT(-0500)] <colinclark> I don't know what thealphanerd thinks...

[20:38:16 CDT(-0500)] <colinclark> he might have drifted away

[20:38:46 CDT(-0500)] <colinclark> It's really badly done

[20:38:58 CDT(-0500)] <colinclark> I notice when I hold a key down for any length of time, it seems to stutter

[20:39:26 CDT(-0500)] <colinclark> and his keyboard events seem to make no distinction between, say, the "U" key being pressed, and Ctrl-U

[20:39:42 CDT(-0500)] <colinclark> which makes the whole thing really annoying

[20:40:39 CDT(-0500)] <colinclark> plus thealphanerd already has support for things like user-specified equal temperaments

[20:41:17 CDT(-0500)] <Bosmon> great

[20:41:31 CDT(-0500)] <Bosmon> and I'm sure we will soon be listening to a synth in WERCKMEISTER *III*!

[20:42:19 CDT(-0500)] <colinclark> I look forward to that quite a bit

[20:44:07 CDT(-0500)] <thealphanerd> sorry

[20:44:16 CDT(-0500)] <thealphanerd> tax drama

[20:44:19 CDT(-0500)] <thealphanerd> but I'm back

[20:44:39 CDT(-0500)] <thealphanerd> colinclark: I took a peak at his code… and it is all one giant block, which is another problem for him

[20:44:52 CDT(-0500)] <colinclark> yeah

[20:44:56 CDT(-0500)] <thealphanerd> my codebase is substaintially more flexble (thanks to infusion)

[20:45:09 CDT(-0500)] <colinclark> it is indeed

[20:45:14 CDT(-0500)] <thealphanerd> before the end I want to make a node osc / midi keyboard too

[20:45:27 CDT(-0500)] <thealphanerd> with all the arpegiator / inclusive stuff

[20:45:28 CDT(-0500)] <thealphanerd> but down the roa

[20:45:28 CDT(-0500)] <thealphanerd> d

[20:45:36 CDT(-0500)] <colinclark> one that can send OSC messages to the server, you mean?

[20:46:01 CDT(-0500)] <thealphanerd> colinclark: osc keyboard… you could send osc messages to a specified address and port

[20:46:03 CDT(-0500)] <thealphanerd> would be the idea

[20:46:07 CDT(-0500)] <colinclark> right

[20:46:13 CDT(-0500)] <thealphanerd> and midi would let you send midi on a selected bus

[20:46:34 CDT(-0500)] <thealphanerd> there are node solutions for each… and it would be suprisingly easy to do both

[20:46:50 CDT(-0500)] <thealphanerd> although I think I would need to learn a bit more about creating component trees

[20:47:12 CDT(-0500)] <thealphanerd> or I will have to write seperate js files for each type of instrument

[20:47:23 CDT(-0500)] <colinclark> One of these days I'll create a bridge from Node.js to PortAudio

[20:47:29 CDT(-0500)] <colinclark> perhaps using node-ffi

[20:47:41 CDT(-0500)] <colinclark> And then you'll be able to run Flocking natively, too

[20:47:47 CDT(-0500)] <colinclark> and sent it OSC messages

[20:47:51 CDT(-0500)] <thealphanerd> sexy

[20:47:54 CDT(-0500)] <thealphanerd> that would be interesting

[20:48:00 CDT(-0500)] <thealphanerd> if flocking ran as a server

[20:48:07 CDT(-0500)] <thealphanerd> that you executed messages to

[20:48:11 CDT(-0500)] <colinclark> I can't imagine it would be all that difficult

[20:48:29 CDT(-0500)] <colinclark> It's just that increasingly, browsers are everywhere

[20:48:42 CDT(-0500)] <thealphanerd> so for polyphony… are we going to try and manage that in flocking land or infusion land

[20:48:57 CDT(-0500)] <thealphanerd> and should it be done using an oscillator bank or by giving each key its own oscillator

[20:49:05 CDT(-0500)] <colinclark> I think you'll make an object that, if you work at it a bit, we can integrate directly into Flocking

[20:49:19 CDT(-0500)] <thealphanerd> ok cool

[20:49:21 CDT(-0500)] <thealphanerd> I like that idea

[20:49:22 CDT(-0500)] <colinclark> In this case, Synth

[20:49:24 CDT(-0500)] <colinclark> but yes

[20:49:30 CDT(-0500)] <colinclark> I guess I don't mind either way

[20:49:39 CDT(-0500)] <thealphanerd> I think it makes more sense to live in flocking

[20:49:43 CDT(-0500)] <colinclark> Probably a bank of synths is the best approach

[20:49:45 CDT(-0500)] <Bosmon> Do I understand that softly-softly, the Infusion flocking revolution has already happened? : P

[20:49:55 CDT(-0500)] <colinclark> well

[20:50:05 CDT(-0500)] <colinclark> thealphanerd is certain on your side, Bosmon

[20:50:14 CDT(-0500)] <Bosmon> There's a side? : P

[20:50:28 CDT(-0500)] <colinclark> But Flocking still avoids depending on Infusion

[20:50:29 CDT(-0500)] <thealphanerd> colinclark: I was thinking a bank of synths would make the most sense to me… as bubbling an update for every key could prove annoying

[20:50:53 CDT(-0500)] <colinclark> it's just that thealphanerd is proving how easy and pleasant it is to write an Infusion app with Flocking

[20:51:02 CDT(-0500)] <Bosmon> Ah, I see

[20:51:07 CDT(-0500)] <colinclark> I suppose I'm getting to the end of the line here

[20:51:21 CDT(-0500)] <thealphanerd> I think thealphanerd is proving how easy and pleasant it is to write an infusion app .

[20:51:23 CDT(-0500)] <thealphanerd>

[20:51:30 CDT(-0500)] <Bosmon> Well, you certainly don't want to be dispatching to an invoker in the middle of a unit generator : P

[20:51:37 CDT(-0500)] <colinclark> indeed

[20:51:40 CDT(-0500)] <Bosmon> But still, I can imagine there are a number of things that might be helpful

[20:51:44 CDT(-0500)] <colinclark> there are quite a number

[20:51:50 CDT(-0500)] <thealphanerd> I think the real trick

[20:51:52 CDT(-0500)] <Bosmon> Especially now we have MODEL TRANSFORMATION in trunk

[20:51:54 CDT(-0500)] <thealphanerd> will be an infusion component

[20:52:05 CDT(-0500)] <Bosmon> And tomorrow, we may also have a version of it that doesn't cause a fatal bug in half the framework : P

[20:52:09 CDT(-0500)] <colinclark> lol

[20:52:41 CDT(-0500)] <thealphanerd> colinclark: I think a bank in flocking land makes sense… that way once there are filters you can apply them both to individual oscillators, or to banks

[20:52:50 CDT(-0500)] <colinclark> yup

[20:52:58 CDT(-0500)] <thealphanerd> you will want banks for polyphony

[20:53:09 CDT(-0500)] <colinclark> I think you'll end up making an object that implements the core interface of a Synth...

[20:53:11 CDT(-0500)] <thealphanerd> but possibly banks for multi-voices as well

[20:53:14 CDT(-0500)] <colinclark> a thing that you can set and get inputs on

[20:53:40 CDT(-0500)] <colinclark> but will add the ability to trigger notes

[20:55:33 CDT(-0500)] <thealphanerd> a lot to think about

[20:55:35 CDT(-0500)] <thealphanerd> that's for sure

[20:55:47 CDT(-0500)] <colinclark> In its simplest form, it shouldn't be too hard

[20:55:52 CDT(-0500)] <thealphanerd> I have to run for now

[20:55:56 CDT(-0500)] <colinclark> sure

[20:55:57 CDT(-0500)] <thealphanerd> colinclark: I'll see you tomorrow

[20:55:57 CDT(-0500)] <colinclark> see you tomorrow