2019-11-13T00:21:04 *** stegru has quit IRC (Ping timeout: 268 seconds) 2019-11-13T00:23:39 *** stegru has joined #fluid-work 2019-11-13T00:30:54 *** sepidehshahi has quit IRC (Quit: sepidehshahi) 2019-11-13T00:31:20 *** sepidehshahi has joined #fluid-work 2019-11-13T00:31:28 *** sepidehshahi has left #fluid-work 2019-11-13T00:55:01 *** yzen has joined #fluid-work 2019-11-13T02:08:42 *** yzen has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) 2019-11-13T02:09:09 *** yzen has joined #fluid-work 2019-11-13T02:13:38 *** yzen has quit IRC (Ping timeout: 245 seconds) 2019-11-13T05:40:35 *** the-t-in-rtf has joined #fluid-work 2019-11-13T08:17:36 morning. 2019-11-13T08:17:37 after last week's problems, I wanted to ask anyone who's online to confirm when they get the note about the pad for today's architecture meeting. 2019-11-13T08:18:33 Looks like the mail server at least got it: 2019-11-13T08:18:34 https://lists.gpii.net/pipermail/architecture/2019-November/005027.html 2019-11-13T09:12:08 yes the-t-in-rtf 2019-11-13T09:21:01 good to hear 2019-11-13T09:49:45 *** jhernandez has joined #fluid-work 2019-11-13T12:00:19 *** yanachkov__ has joined #fluid-work 2019-11-13T12:08:22 Bosmon: I didn't get a chance to finish looking at the upwards distribution issue yesterday. I have a bit of time this morning that I'll try to look at it more. I did write up a simple example to test upward distribution and it worked using the FLUID-6148 branch, so it's probably something specific to composite panels/sub panels. 2019-11-13T12:08:50 Justin_o - ok, that's fine 2019-11-13T12:09:08 We just need to make sure that nothing tries to evaluate the selectors before the distribution bites 2019-11-13T12:09:11 Which in theory should be easy 2019-11-13T12:09:37 Since I can't think of anything in the new framework which could, "container" is now an ordinary "member" with a standard definition like anything else 2019-11-13T12:09:45 Unlike the "special magic" it was in the old framework 2019-11-13T12:09:47 Bosmon: I actually tried to distribute to a new option, and that didn't even work. so not really sure what is causing the problem 2019-11-13T12:10:10 Justin_o - ok, possibly just a basic typo of some kind then 2019-11-13T12:10:36 Bosmon: here's the configuration 2019-11-13T12:10:43 https://www.irccloud.com/pastebin/OjHtB3M9/ 2019-11-13T12:10:50 that's just the distribution part 2019-11-13T12:11:15 I should talk you through a few basic "jungle skills" in helping you debug/inspect such things anyway : P 2019-11-13T12:11:41 The first key is to find the "shadow" for the component which you expect to get hit by the distribution 2019-11-13T12:11:52 And you can find all of these indexed in fluid.globalInstantiator.idToShadow 2019-11-13T12:12:12 Then inside there is "mergeOptions" which contains an array called "mergeBlocks" 2019-11-13T12:12:29 If the distribution has hit, you should expect to find a record inside mergeBlocks which corresponds to it 2019-11-13T12:12:39 These details are the same in the old and the new framework, so these skills are transferrable : P 2019-11-13T12:13:18 thanks :) 2019-11-13T12:14:37 Justin_o - that's odd, you're saying that nothing at all ends up in the "testing" option of the compositePanel? 2019-11-13T12:16:29 this is the options for the parent composite panel after initialization 2019-11-13T12:16:37 https://www.irccloud.com/pastebin/4CxYjHEc/ 2019-11-13T12:16:51 Very odd 2019-11-13T12:16:56 Well, check that in and I will take a look at it 2019-11-13T12:17:34 Bosmon: thanks, I'll do that 2019-11-13T12:17:47 Bosmon: I wonder if it's related to these invokers in the gradeNames https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L217 2019-11-13T12:18:25 which actually end up creating a options distribution to distribute the "fluid.prefs.subPanel" grade to the panels that are used as sub panels. 2019-11-13T12:18:26 https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L281-L283 2019-11-13T12:18:59 https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L324-L359 2019-11-13T12:19:18 it all looks so convoluted ;( 2019-11-13T12:19:49 Justin_o - not that, but THIS: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L432 2019-11-13T12:19:58 I hadn't realised that all these subcomponents are createOnEvent 2019-11-13T12:19:59 ? 2019-11-13T12:20:35 In which case there is no way that the distribution can bite 2019-11-13T12:20:45 ah 2019-11-13T12:21:00 So these components don't actually exist at the point of onCreate? 2019-11-13T12:21:03 I don't think I even realized that was a thing, but makes sense 2019-11-13T12:21:10 I see 2019-11-13T12:21:16 No wonder we introspect for them into options.components 2019-11-13T12:21:21 This is all the most unholy mess 2019-11-13T12:21:46 I think we had to do that for the timing with the rendering 2019-11-13T12:21:51 Justin_o - I imagine we did 2019-11-13T12:22:01 Let me just go and take the compost out and think what is to do about this ... 2019-11-13T12:22:38 thanks 2019-11-13T12:26:36 Bosmon: well they already aren't renderOnInit... is that enough to not require createOnEvent? 2019-11-13T12:26:56 https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L126 2019-11-13T12:35:55 OK, there was rather more compost than I expected 2019-11-13T12:36:38 Justin_o - well I don't think we can revise a decision at this point as fundamental as whether the subpanels are createOnEvent or not 2019-11-13T12:36:46 No doubt there are numerous deep and evil reasons for this 2019-11-13T12:37:31 Bosmon: yes, I was just imagining how much of this structure I'd have to unravel to get rid of the create on event and simplify the distributions and etc 2019-11-13T12:37:42 Justin_o - anyway, my compost walk has suggested the WAY OUT 2019-11-13T12:38:11 Which is suggested by this devilish function itself, "subPanelLifecycleBindings" 2019-11-13T12:38:47 Bosmon: okay, I'm curious 2019-11-13T12:39:10 So, there is already quite enough grade synthesis magic lying around here that a little more won't hurt us that much more : P 2019-11-13T12:39:20 This function synthesizes a whole grade definition that gets overlaid onto us 2019-11-13T12:40:00 So there is no reason that we can't then also synthesize an selectors: { expander: { thing}} definition as well, that just contains the body of the current surfaceSubpanelRendererSelectors 2019-11-13T12:40:24 Minus the "set" junk of course, but just turn that into a standard function that does the crazy introspection and then returns the required selector entries 2019-11-13T12:42:47 Bosmon: ah that seems reasonable.. so we have fewer locations doing the prefetch too, and just apply it onto with standard grade merging instead manually changing the options after the fact 2019-11-13T12:43:10 Yes, I think this solution compounds the existing design crimes as little as possible, and sort of "rolls with them" : P 2019-11-13T12:44:39 haha. yep.. seems the best case if we are going to get rid of all of this in upcoming framework changes anyways. 2019-11-13T12:46:32 All this rampant grade synthesis makes it extremely hard to get a design overview of what anything is doing 2019-11-13T12:46:50 I am hoping that lensed components are now powerful enough for us to be able to write all these definitions in directly 2019-11-13T12:47:03 that would be really helpful 2019-11-13T12:47:06 but in any case all the "createOnEvent" annotations will be axed anyway so it wouldn't matter 2019-11-13T12:47:38 I mean, it wouldn't matter that we couldn't read that in particular except through looking into the implementation of the function that we happened to know was responsible : P 2019-11-13T12:50:11 Bosmon: it's almost funny in a way, that if you look through the code, it appears I did as much as possible to obsfucate how things actually come together. 2019-11-13T12:51:12 Justin_o - well, you did your best, given the framework you had been given to work with : P 2019-11-13T12:51:44 I mean, did your best to express the design clearly, not did your best to obfuscate things : P 2019-11-13T12:52:43 lol thanks 2019-11-13T12:57:11 Bosmon: I'll be away for the rest of the day, but will dive back into this tomorrow. Thanks again for the help. 2019-11-13T13:40:59 *** cindyli has joined #fluid-work 2019-11-13T13:57:55 *** jhernandez has quit IRC (Read error: Connection reset by peer) 2019-11-13T13:57:55 *** danielcho has joined #fluid-work 2019-11-13T14:04:51 *** sepidehshahi has joined #fluid-work 2019-11-13T14:18:15 *** avtar has joined #fluid-work 2019-11-13T14:22:46 *** avtar has quit IRC (Client Quit) 2019-11-13T14:47:28 *** avtar has joined #fluid-work 2019-11-13T15:02:14 *** simonjb has joined #fluid-work 2019-11-13T15:07:27 *** clown has joined #fluid-work 2019-11-13T15:10:26 *** cherylhjli has joined #fluid-work 2019-11-13T15:15:29 *** simonjb has quit IRC () 2019-11-13T15:30:19 *** michelled has joined #fluid-work 2019-11-13T15:47:12 *** avtar has quit IRC (Quit: Quit) 2019-11-13T15:53:48 *** jhung has joined #fluid-work 2019-11-13T15:54:20 *** michelled has quit IRC (Quit: Leaving.) 2019-11-13T15:57:45 *** michelled has joined #fluid-work 2019-11-13T15:59:22 *** simonjb has joined #fluid-work 2019-11-13T16:00:01 *** colinclark has joined #fluid-work 2019-11-13T16:11:03 *** colinclark has quit IRC (Quit: colinclark) 2019-11-13T16:25:32 *** danayo_ has joined #fluid-work 2019-11-13T16:26:53 *** colinclark has joined #fluid-work 2019-11-13T16:51:37 *** yanachkov__ has quit IRC (Ping timeout: 240 seconds) 2019-11-13T16:52:07 *** sepidehshahi has left #fluid-work 2019-11-13T16:58:23 *** clown is now known as clown_mtg 2019-11-13T17:04:04 *** colinclark has quit IRC (Quit: colinclark) 2019-11-13T17:09:25 *** michelled has quit IRC (Quit: Leaving.) 2019-11-13T17:13:34 *** michelled has joined #fluid-work 2019-11-13T17:59:02 *** colinclark has joined #fluid-work 2019-11-13T18:23:10 *** danayo_ has quit IRC (Quit: danayo_) 2019-11-13T18:24:45 *** danayo_ has joined #fluid-work 2019-11-13T18:30:37 *** danayo_ has quit IRC (Quit: danayo_) 2019-11-13T18:32:44 *** danayo_ has joined #fluid-work 2019-11-13T18:44:41 *** jhernandez has joined #fluid-work 2019-11-13T18:50:19 *** danayo_ has quit IRC (Quit: danayo_) 2019-11-13T18:50:58 *** danayo_ has joined #fluid-work 2019-11-13T19:06:17 *** jhernandez has quit IRC (Quit: jhernandez) 2019-11-13T19:07:00 *** danayo_ has quit IRC (Quit: danayo_) 2019-11-13T19:14:54 *** danayo_ has joined #fluid-work 2019-11-13T19:39:13 *** cindyli has quit IRC (Quit: Leaving.) 2019-11-13T20:00:39 *** jhernandez has joined #fluid-work 2019-11-13T20:16:16 *** cindyli has joined #fluid-work 2019-11-13T20:25:24 *** avtar has joined #fluid-work 2019-11-13T20:34:37 *** clown_mtg has quit IRC (Ping timeout: 240 seconds) 2019-11-13T20:49:14 *** danayo_ has quit IRC (Quit: danayo_) 2019-11-13T21:05:34 *** clown has joined #fluid-work 2019-11-13T21:08:02 *** cindyli has quit IRC (Quit: Leaving.) 2019-11-13T21:11:48 *** danielcho1 has joined #fluid-work 2019-11-13T21:12:19 *** danayo_ has joined #fluid-work 2019-11-13T21:13:37 *** jhernandez has quit IRC (Quit: jhernandez) 2019-11-13T21:15:22 *** danielcho has quit IRC (Ping timeout: 268 seconds) 2019-11-13T21:17:42 *** cindyli has joined #fluid-work 2019-11-13T21:25:12 *** danielcho1 has left #fluid-work 2019-11-13T21:33:32 *** cindyli has quit IRC (Quit: Leaving.) 2019-11-13T21:34:18 *** jhung has quit IRC (Quit: Leaving) 2019-11-13T21:38:17 Bosmon: (when you have a moment) I'm back on SJRK-255 and am thinking about how to handle this comment: https://github.com/fluid-project/sjrk-story-telling/pull/35#pullrequestreview-270689695 2019-11-13T21:38:17 Is there a way to call a component's change applier and supply multiple values/changes in a single call? I.e. I want to turn the onShareRequested listener into one call rather than three, if possible. 2019-11-13T21:39:15 I suppose I could have a single model value that represents "attempting to publish and waiting for the server to respond", like "publishingState" 2019-11-13T21:39:20 and model relays 2019-11-13T21:41:07 gmoss - yes, that is one model 2019-11-13T21:41:22 The other would be to batch a lot of updates into a transaction as so: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/PrefsEditor.js#L433 2019-11-13T21:41:28 Bosmon: I think what I'm attempting to do currently is not exactly what you suggested, but close to it 2019-11-13T21:42:25 Bosmon: oh that's a good idea, I'd forgotten about the initiate function as I hadn't used it yet 2019-11-13T21:42:44 It seems esoteric but in practice one needs it more than one might think 2019-11-13T21:42:59 A lack of transactions is one of the greatest annoyances of primitive data synchronisation frameworks 2019-11-13T21:43:27 Our current API is a bit boneheaded in its 1990s object-y style, but it's better than a poke in the eye : P 2019-11-13T21:46:04 Bosmon: haha indeed, and better than having to wrangle JS objects directly and manage state change manually 2019-11-13T21:46:44 Thanks for the tips :) 2019-11-13T21:46:47 Well, it's arguable whether the endless wrinkles in the "old" framework really do make for a net improvement : P 2019-11-13T21:47:00 But we hope that with the coming update we might at least break even .... 2019-11-13T21:48:39 The great patience and steady dedication of the team is a fine asset :) 2019-11-13T21:50:34 Bosmon: that team, of course, includes you too! usable documentation doesn't hurt either ;) 2019-11-13T21:52:48 Well, you can thank the-t-in-rtf and Justin_o for most of the work on that 2019-11-13T21:53:25 Interesting that even after all these years, anastasiac is still showing up with the greatest number of lines added ... 2019-11-13T21:53:49 Oh wait, it is simonjb! 2019-11-13T21:53:56 Just from way fewer commits 2019-11-13T21:57:43 *** michelled has quit IRC (Quit: Leaving.) 2019-11-13T22:01:18 *** clown has quit IRC (Quit: Leaving.) 2019-11-13T22:08:29 *** cherylhjli1 has joined #fluid-work 2019-11-13T22:09:22 *** cherylhjli has quit IRC (Read error: Connection reset by peer) 2019-11-13T22:22:42 *** simonjb has quit IRC () 2019-11-13T22:25:14 *** avtar has quit IRC (Quit: Quit) 2019-11-13T22:31:49 *** Bosmon2 has joined #fluid-work 2019-11-13T22:32:27 *** danayo_ has quit IRC (Quit: danayo_) 2019-11-13T22:32:57 *** Bosmon has quit IRC (Ping timeout: 240 seconds) 2019-11-13T23:24:12 *** colinclark has quit IRC (Quit: colinclark)