fluid-work IRC Logs-2008-11-06

Owned by Fluid IRC Log Bot
Last updated: Nov 06, 2008Version comment
10 min read

[00:41:50 EST(-0500)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[01:15:34 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:36:54 EST(-0500)] * ptmahent (n=ptmahent@kb-v832-130-63-234-498.airyork.yorku.ca) has joined #fluid-work
[08:39:35 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has left #fluid-work
[08:41:29 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:56:30 EST(-0500)] * ptmahent__ (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[09:58:24 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:04:07 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:07:30 EST(-0500)] * Topic is 'the water that rolls back down a beach after a wave has broken' set by michelled on 2008-11-06 10:07:30 EST(-0500)
[10:10:47 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:22:44 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:46:44 EST(-0500)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[10:47:25 EST(-0500)] <Bosmo1> So - OK
[10:47:35 EST(-0500)] <Bosmo1> it looks like we have a tidy collection of new InlineEdit JIRAs
[10:47:37 EST(-0500)] <Bosmo1> ta AC (tongue)
[10:52:23 EST(-0500)] * ptmahent (n=ptmahent@kb-v832-130-63-234-498.airyork.yorku.ca) has joined #fluid-work
[11:05:35 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[11:18:54 EST(-0500)] <anastasiac> Bosmo1, yes
[11:19:06 EST(-0500)] <anastasiac> these came out of our conversation yesterday
[11:19:48 EST(-0500)] <anastasiac> echochran has posted a patch for some of them - colinclark and I are reviewing his patch this morning
[11:20:49 EST(-0500)] <colinclark> anastasiac: I missed Bosmo1's question.
[11:20:52 EST(-0500)] <colinclark> The Inline Edit issues?
[11:20:59 EST(-0500)] <Bosmo1> Ah
[11:21:03 EST(-0500)] <Bosmo1> I am drawing a little diagram with arrows
[11:21:13 EST(-0500)] <Bosmo1> In the usual way, when things get bad (tongue)
[11:21:18 EST(-0500)] <colinclark> arrows!
[11:21:21 EST(-0500)] <Bosmo1> (16:12:00) Antranig: I am getting my head tied in knots thinking about FLUID-1321/1662
[11:21:26 EST(-0500)] <colinclark> (smile)
[11:21:59 EST(-0500)] <colinclark> Bosmo1: 1321 is marked as fixed.
[11:22:03 EST(-0500)] <Bosmo1> Yes, it is
[11:22:18 EST(-0500)] <Bosmo1> But I believe the strategy it is using is responsible for the behaviour of FLUID-1662
[11:22:26 EST(-0500)] <Bosmo1> Although I am not yet fully convinced
[11:22:35 EST(-0500)] <Bosmo1> So I am drawing a diagram with lots of little arrows (smile)
[11:22:35 EST(-0500)] <colinclark> Ah, interesting.
[11:22:40 EST(-0500)] <colinclark> Cool.
[11:22:45 EST(-0500)] <colinclark> So I will tell you about my day.
[11:22:49 EST(-0500)] <anastasiac> I look forward to seeing the diagram
[11:22:50 EST(-0500)] <colinclark> I just finished talking to anastasiac.
[11:22:51 EST(-0500)] <Bosmo1> This component is actually deceptively complex
[11:22:56 EST(-0500)] <Bosmo1> The Undo manager, I mean
[11:23:10 EST(-0500)] <Bosmo1> It appeared completely trivial, when first designed
[11:23:10 EST(-0500)] <colinclark> Lots going on. I'm going to tweak Eli's patch.
[11:23:14 EST(-0500)] <Bosmo1> ok
[11:23:26 EST(-0500)] <colinclark> Then I'm going to slip out for a few hours to cut more ABS pipes.
[11:23:47 EST(-0500)] <colinclark> I've got a lot of writing to do, but I'd like to talk with you, Bosmo1, either today or tomorrow.
[11:23:52 EST(-0500)] <colinclark> I'd like to continue our pipe cutting conversation.
[11:24:23 EST(-0500)] <colinclark> Also known as "event arguments a la carte."
[11:24:31 EST(-0500)] <Bosmo1> Yes
[11:24:34 EST(-0500)] <Bosmo1> ok
[11:24:50 EST(-0500)] <Bosmo1> Remind me what your pipes are for? (tongue)
[11:25:07 EST(-0500)] <colinclark> Bosmo1: They serve as a framework.
[11:25:08 EST(-0500)] <colinclark> (tongue)
[11:25:19 EST(-0500)] <colinclark> For the boat tarp.
[11:26:28 EST(-0500)] <Bosmo1> ha
[11:26:36 EST(-0500)] <Bosmo1> So nothing actually flows through them
[11:26:39 EST(-0500)] <Bosmo1> They are purely structural?
[11:27:10 EST(-0500)] <colinclark> Yes, exactly.
[11:27:31 EST(-0500)] <colinclark> They seemed more convenient and less chafe-prone than a wood frame.
[11:27:45 EST(-0500)] <colinclark> So, Bosmo1, just to confirm:
[11:28:36 EST(-0500)] <colinclark> We are firing modelChanged() upon initialization simply because we are reusing the behaviour in updateModel(), correct?
[11:28:57 EST(-0500)] <colinclark> I can't imagine it's ever meaningful to fire modelChanged() intentionally on startup.
[11:29:09 EST(-0500)] <Bosmo1> That could be correct, yes
[11:29:20 EST(-0500)] <colinclark> Ok.
[11:29:23 EST(-0500)] <Bosmo1> I was just eying the other duplicate logic in Undo
[11:29:34 EST(-0500)] <Bosmo1> Two sets of calls to refreshView
[11:29:39 EST(-0500)] <colinclark> Aha
[11:29:56 EST(-0500)] <Bosmo1> This code, though pretty well structured, is already pretty hard to think clearly about
[11:30:02 EST(-0500)] <colinclark> in bindHandler(), you mean?
[11:30:08 EST(-0500)] <Bosmo1> yes
[11:30:27 EST(-0500)] <colinclark> Bosmo1: I am beginning to think differently about Undo. But it would be better for a voice conversation.
[11:30:45 EST(-0500)] <colinclark> I'm just not sure what we've got is structurally right, but as you say, it's hard to think clearly about it.
[11:31:10 EST(-0500)] <colinclark> I'm beginning to think that the idea of sharing a UI for undo is actually not a common case...
[11:31:22 EST(-0500)] <Bosmo1> What do you mean?
[11:31:29 EST(-0500)] <colinclark> since undo will look and feel very differently when applied to different components.
[11:31:32 EST(-0500)] <colinclark> Or even different contexts.
[11:31:47 EST(-0500)] <Bosmo1> Sharing, with what scope?
[11:32:03 EST(-0500)] <colinclark> Well, let me try to put it a different way...
[11:32:15 EST(-0500)] <colinclark> I wonder if perhaps the View part of Undo is not actually particularly reusable.
[11:32:39 EST(-0500)] <Bosmo1> You mean... the bit that draws the little controls for undo and redo?
[11:32:41 EST(-0500)] <colinclark> And that the modelly parts of it should be structured differently than as a decorator.
[11:32:49 EST(-0500)] <colinclark> Well, yes.
[11:33:14 EST(-0500)] <colinclark> And this ties in with the relationship between the Undo and the events offered by its decoratee.
[11:34:18 EST(-0500)] <Bosmo1> I think I have located a chap with RALPH (smile)
[11:34:22 EST(-0500)] <Bosmo1> RALPH RALPH RALPH
[11:35:38 EST(-0500)] <colinclark> excellent
[11:36:33 EST(-0500)] <Bosmo1> FLUID-1321/1662 has really got my head in a spin, even with the arrows...
[11:36:41 EST(-0500)] <Bosmo1> This is just the sort of question I was terrible at in CS exams
[11:36:44 EST(-0500)] <colinclark> (smile)
[11:37:33 EST(-0500)] <Bosmo1> I guess we can adopt as an "axiom" that the effect of an undo followed by a redo is "idempotent"?
[11:37:47 EST(-0500)] <Bosmo1> That is, the entire state of the component becomes indistinguishable to the way it was before the undo
[11:38:03 EST(-0500)] <Bosmo1> Including any "hidden variables"...
[11:48:19 EST(-0500)] <colinclark> one sec
[11:56:36 EST(-0500)] <colinclark> Bosmo1: That seems like a perfectly reasonable assumption to make.
[11:56:50 EST(-0500)] <colinclark> What "hidden variables" are you worried about?
[11:56:59 EST(-0500)] <Bosmo1> Our stored "models"
[11:57:02 EST(-0500)] <Bosmo1> Which is what this is all about...
[11:57:56 EST(-0500)] <colinclark> you mean, the values in the DOM?
[11:58:03 EST(-0500)] <Bosmo1> No, in the Undo manager
[11:58:05 EST(-0500)] <colinclark> Since our plain old JS model is perfectly visible.
[11:58:07 EST(-0500)] <colinclark> Ah, yes
[11:58:08 EST(-0500)] <colinclark> I see.
[11:58:18 EST(-0500)] <colinclark> It's snapshots, in other words.
[11:58:24 EST(-0500)] <Bosmo1> ys
[11:58:25 EST(-0500)] <colinclark> Its
[11:58:47 EST(-0500)] <colinclark> yes, i think that's reasonable
[12:00:12 EST(-0500)] <Bosmo1> Ah.... the Undo -> Edit transition is somewhat "special"...
[12:01:04 EST(-0500)] <Bosmo1> Given that we certainly then have to support the affordance of Undo, we probably would want to lose the affordance of "Reo"
[12:01:07 EST(-0500)] <Bosmo1> Redo
[12:01:29 EST(-0500)] <Bosmo1> Although our current UI model doesn't really call upon us to accommodate the simultaneous visibility of Undo and Redo
[12:01:40 EST(-0500)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:02:01 EST(-0500)] <Bosmo1> However, given the two pieces of state we keep, this is the unique case where we could show them both
[12:02:22 EST(-0500)] <Bosmo1> With a more sophisticated Undo Manager, they could be both visible at many more times
[12:03:20 EST(-0500)] <colinclark> Bosmo1: Yes, definitely
[12:03:32 EST(-0500)] <colinclark> Once we support an undo stack, we'll need this ability.
[12:04:34 EST(-0500)] <colinclark> Ok, I'll see you all in a few hours.
[12:13:21 EST(-0500)] * ptmahent (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[12:20:25 EST(-0500)] <Bosmo1> Gah
[12:20:45 EST(-0500)] <Bosmo1> Colin seems to have scarpered without dealing with the FLUID-177X patch
[12:21:11 EST(-0500)] <anastasiac> he posted an alternate patch on 1772, I believe
[12:25:25 EST(-0500)] <Bosmo1> yes
[12:25:38 EST(-0500)] <Bosmo1> But it is a bit awkward, since I am about to do some work which might interfere with this...
[12:25:57 EST(-0500)] <Bosmo1> The arrows now tell me that our handling of state in the Undo manager is very definitely wrong
[12:26:02 EST(-0500)] <anastasiac> might your work affect the need for the patch?
[12:26:56 EST(-0500)] <Bosmo1> No, I don't think so
[12:27:10 EST(-0500)] <Bosmo1> But there are an awful lot of changes we seem to need to make to InlineEdit/Undo "all at once"
[12:27:23 EST(-0500)] <Bosmo1> We will have to be careful they don't all tread on each other's toes
[12:27:52 EST(-0500)] * ptmahent (n=ptmahent@kd-v226-130-63-226-320.airyork.yorku.ca) has joined #fluid-work
[12:27:54 EST(-0500)] <anastasiac> well, perhaps review his patch. If it looks reasonable to you, and in line with what you feel needs to be done, then you could commit it before you begin your work
[12:28:04 EST(-0500)] <anastasiac> I'm just reviewing it now...
[12:31:57 EST(-0500)] <anastasiac> the patch looks good to me, Bosmo1 - have you looked at it?
[12:33:05 EST(-0500)] <anastasiac> ok - I take that back! It breaks all the tests
[12:33:15 EST(-0500)] <anastasiac> it shouldn't be committed until that's addressed
[12:33:37 EST(-0500)] <anastasiac> the samples would also need to be updated to the new API
[12:37:19 EST(-0500)] <Bosmo1> Great....
[12:37:44 EST(-0500)] <Bosmo1> I guess I am thinking I should do this work first then (tongue)
[12:37:48 EST(-0500)] <anastasiac> but other than that, have you looked at the patch?
[12:38:13 EST(-0500)] <Bosmo1> You changed the Undo handler to bind to "afterFinish" rather than "onFinish"
[12:38:20 EST(-0500)] <Bosmo1> I am trying to think why
[12:38:28 EST(-0500)] <anastasiac> not me...
[12:38:40 EST(-0500)] <Bosmo1> It was you!
[12:38:41 EST(-0500)] <Bosmo1> (smile)
[12:38:52 EST(-0500)] <Bosmo1> rev 5718
[12:39:03 EST(-0500)] <Bosmo1> But, I think I understand vaguely...
[12:39:06 EST(-0500)] <anastasiac> ah, right, ok
[12:39:11 EST(-0500)] <anastasiac> yes, there was a reason...
[12:39:14 EST(-0500)] <Bosmo1> And this patch I think is related
[12:39:23 EST(-0500)] <Bosmo1> In fact, you are caught between two rocks in this case
[12:39:31 EST(-0500)] <anastasiac> quite possibly - that sounds really familiar (smile)
[12:39:36 EST(-0500)] <anastasiac> the rocks part
[12:39:36 EST(-0500)] <Bosmo1> In fact, we can't implement this part of undo properly without reliable access to BOTH old and new values
[12:39:43 EST(-0500)] <anastasiac> exactly
[12:39:47 EST(-0500)] <Bosmo1> Now, you changed it from one form to the other
[12:39:57 EST(-0500)] <Bosmo1> Which actually just swapped one set of problems for another
[12:40:05 EST(-0500)] <anastasiac> yes, I remember not being entirely comfortable with the solution
[12:40:19 EST(-0500)] <anastasiac> do you have ideas for how to refactor all of this?
[12:40:26 EST(-0500)] <Bosmo1> "opportunistically", the "current value" is sometimes available in the "extremalModel"
[12:40:33 EST(-0500)] <Bosmo1> But actually, the arrows tell me this is not always the case
[12:40:58 EST(-0500)] <Bosmo1> So your test of "current value versus extremal value" is only sometimes correct
[12:41:03 EST(-0500)] <anastasiac> anywhere I can go to see these arrows?
[12:41:23 EST(-0500)] <Bosmo1> I guess I could try to scan them
[12:41:29 EST(-0500)] <Bosmo1> They are on a yellow post-it note...
[12:41:38 EST(-0500)] <anastasiac> ah - old-fashioned...
[12:41:45 EST(-0500)] <Bosmo1> But, the diagram is incredibly unreadable
[12:42:19 EST(-0500)] <anastasiac> don't worry about it then - as long as you understand (smile)
[12:42:32 EST(-0500)] <anastasiac> I remember trying to draw a diagram - also unreadable by anyone but me
[12:49:35 EST(-0500)] <Bosmo1> So... the purpose of this 1772 patch is simply to prevent a call to updateModel initially?
[12:49:42 EST(-0500)] <Bosmo1> It seems a bit weak to me
[12:49:52 EST(-0500)] <Bosmo1> Since even fixing that, we have numerous inconsistencies in the meaning of updateModel
[12:49:57 EST(-0500)] <Bosmo1> It would seem better to fix them all at once
[12:51:23 EST(-0500)] <Bosmo1> Gah
[12:51:32 EST(-0500)] <Bosmo1> Colin's patch isn't even addresse at the same issue set as Eli's
[12:51:35 EST(-0500)] <Bosmo1> addressed
[12:55:31 EST(-0500)] <Bosmo1> Do we really need to wait quite so long for FLUID-1770?
[13:18:53 EST(-0500)] * ptmahent (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[13:20:01 EST(-0500)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:21:01 EST(-0500)] * JohnNorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:23:26 EST(-0500)] * JohnNorman (n=john@ginger.caret.cam.ac.uk) has left #fluid-work
[13:26:16 EST(-0500)] <anastasiac> Bosmo1, do you have a sense of how to re-work Undo, and how long it will take?
[13:26:35 EST(-0500)] <Bosmo1> Yes
[13:26:44 EST(-0500)] <Bosmo1> And I plan to have that bit of it done today
[13:26:54 EST(-0500)] <anastasiac> what is your estimate for the reworking?
[13:27:04 EST(-0500)] <Bosmo1> I feel we have to be more aggressive with our schedule for API changes
[13:27:23 EST(-0500)] <Bosmo1> For a start, wouldn't the "standard" deprecation cycle imply removing FLUID-1770 for 0.8, not for 0.9?
[13:27:39 EST(-0500)] <Bosmo1> Also, it seems the "onFinish" event which Undo was listening for was simply never implemented
[13:27:54 EST(-0500)] <Bosmo1> And were it to be implemented (as I am doing now), the naming scheme seems simply inconsistent
[13:27:58 EST(-0500)] <anastasiac> I just wrote the JIRA with what colinclark suggested
[13:28:08 EST(-0500)] <anastasiac> I'm trying to plan for the next two iterations
[13:28:12 EST(-0500)] <Bosmo1> The complete set SHOULD be (onBeginEdit, afterBeginEdit, onFinishEdit, afterFinishEdit)
[13:28:23 EST(-0500)] <anastasiac> Do you have an estimate for the refactoring of Undo?
[13:28:28 EST(-0500)] <Bosmo1> Yes
[13:28:32 EST(-0500)] <Bosmo1> I was planning to have it done today
[13:28:42 EST(-0500)] <anastasiac> Excellent!
[13:28:56 EST(-0500)] <anastasiac> does it need its own JIRA, or would it be committable to the ones filed yesterday?
[13:29:11 EST(-0500)] <Bosmo1> But my current plan is to insist on renaming these events NOW.... rather than for 0.8 or 0.9 (tongue)
[13:29:31 EST(-0500)] <anastasiac> ok - why don't you file a JIRA that describes what you're going to address
[13:29:36 EST(-0500)] <Bosmo1> ok
[13:29:52 EST(-0500)] <anastasiac> I'll mark yesterday's JIRAs as dependent on it, and we'll suspend that work
[13:30:04 EST(-0500)] <anastasiac> once you've committed your code, we'll see if those issues are still relevant
[13:30:26 EST(-0500)] <anastasiac> sound reasonable?
[13:30:29 EST(-0500)] <Bosmo1> Yes
[13:30:40 EST(-0500)] <Bosmo1> Could we not really destroy "finishedEditing" right now?
[13:32:04 EST(-0500)] <anastasiac> let's focus on one thing at a time
[13:32:09 EST(-0500)] <Bosmo1> (tongue)
[13:32:19 EST(-0500)] <anastasiac> refactor Undo, and if Inline Edit changes to accommodate the new Undo, ok
[13:32:34 EST(-0500)] <anastasiac> once that's done, if finishedEditing is no longer relevant, we'll take care of it
[13:34:03 EST(-0500)] * ptmahent__ (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[13:36:56 EST(-0500)] * ptmahent (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[13:59:30 EST(-0500)] * ecochran (n=ecochran@adsl-70-137-186-61.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[14:19:16 EST(-0500)] * ecochran (n=ecochran@adsl-70-137-186-61.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[15:18:15 EST(-0500)] <anastasiac> Bosmo1, michelled just reminded me that finishedEditing is the function we are deprecating
[15:18:32 EST(-0500)] <anastasiac> We don't want to just remove it, because it is part of our public API, and implementors are using it
[15:18:50 EST(-0500)] <anastasiac> we will deprecate it until 0.9 to give implementors time to switch over to the new API
[15:19:01 EST(-0500)] <anastasiac> (thanks for catching that, michelled)
[15:26:24 EST(-0500)] <anastasiac> ecochran, you may wish to review the chat logs for earlier today
[15:27:02 EST(-0500)] <anastasiac> Bosmo1 is planning to rework the semantics of modelChanged
[15:27:17 EST(-0500)] <anastasiac> his changes might precipitate other changes in Undo and Inline Edit
[15:27:53 EST(-0500)] <ecochran> Bosmo1, michelled, anastasiac : the finishedEditing function has not been removed yet, just commented on in code.
[15:28:03 EST(-0500)] <ecochran> I'm watching his changes. Thanks
[15:28:13 EST(-0500)] <ecochran> I'll go review the other comments
[15:28:34 EST(-0500)] <anastasiac> ecochran, no - it shouldn't be removed yet, just deprecated
[15:28:43 EST(-0500)] <anastasiac> thanks for the comments in the code
[15:34:40 EST(-0500)] <ecochran> Bosmo1: do you have a sense of what changes are still to come in Undo and how they will effect the current syntax of Inline Edit... I don't think that I need specifics, just a nice "not so much" or "you're screwed"
[15:34:54 EST(-0500)] <ecochran> (wink)
[15:35:53 EST(-0500)] <ecochran> and I suppose I don't even care so much about the Component as I do about my current implementation in Section Info
[15:36:00 EST(-0500)] <ecochran> the sample-code
[15:36:12 EST(-0500)] <anastasiac> ecochran, I think Bosmo1 is away right now...
[15:36:17 EST(-0500)] <ecochran> glarg
[15:36:40 EST(-0500)] <ecochran> yes, it looks that way
[15:37:22 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[16:01:38 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[17:40:24 EST(-0500)] <Bosmon> Hello
[17:40:26 EST(-0500)] <Bosmon> Am I here now?
[17:47:49 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:58:18 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[18:58:18 EST(-0500)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[19:39:27 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[19:59:23 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[20:46:32 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[21:07:52 EST(-0500)] * ptmahent (n=ptmahent@74.12.29.122) has joined #fluid-work
[23:01:57 EST(-0500)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[23:44:21 EST(-0500)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work