fluid-work IRC Logs-2012-09-19

[08:24:35 CDT(-0500)] <Justin_o> cindyli: i think i'm going to move the loadJSONFile and writeToJSONFile functions i have to the utils io

[08:25:02 CDT(-0500)] <cindyli> sounds good, Justin_o

[09:03:21 CDT(-0500)] <jessm> anastasiac: ping

[09:03:44 CDT(-0500)] <anastasiac> hey, jessm, I'm just on a call right now

[09:03:57 CDT(-0500)] <jessm> anastasiac: ok, no worries – i'll just type – read later...

[09:04:51 CDT(-0500)] <jessm> the custom theme in the wiki has gotten impossible with the latest upgrade. I'm wondering if you can dig in and have an impact. we probably need to consider leaving the custom template in favor of a standard one that will wear better with upgrades

[09:04:57 CDT(-0500)] <jessm> ping me when you're ready and we can chat more

[09:13:49 CDT(-0500)] <anastasiac> hey, jessm, I'm off my call now. Yes, I'd be happy to look into the confluence theme. I did modify the base font a bit yesterday – I couldn't stand it anymore – but it was a temporary hack

[09:14:12 CDT(-0500)] <anastasiac> the current theme is a deprecated theme with a custom stylesheet overtop

[09:14:26 CDT(-0500)] <anastasiac> it probably didn't weather because it's deprecated

[09:15:32 CDT(-0500)] <jessm> anastasiac: can you do some sniffing into what it might mean for us to switch to a non-custom theme?

[09:17:27 CDT(-0500)] <anastasiac> sure, jessm. fyi, confluence ships with three out-of-the-box themes (plus the one we're using), and they're all designed to allow you to customize colours, plus possible a few other things, and they all allow you to lay a custom stylesheet overtop. That's the usual way of tweaking a confluence site. I'll do some research into other options, etc

[09:19:34 CDT(-0500)] <jessm> anastasiac: hold on… not sure i understand

[09:20:21 CDT(-0500)] <jessm> anastasiac: maybe you can lay out our options?

[09:21:07 CDT(-0500)] <anastasiac> sure, jessm. I'll do a bit of research into whether or not we have any more options besides the following, but what I see now as options are:

[09:21:27 CDT(-0500)] <anastasiac> a) use one of the built-in confluence themes, as is

[09:21:49 CDT(-0500)] <anastasiac> b) use one of the built-in confluence themes, with a bit of tweaking of colour schemes

[09:22:08 CDT(-0500)] <anastasiac> c) use one of the built-in confluence themes, with a bit of tweaking of colour schemes and with a custom stylesheet added for further customization

[09:22:33 CDT(-0500)] <anastasiac> d) find a whole other existing confluence theme somewhere on the inter webs, download it and apply it

[09:22:51 CDT(-0500)] <anastasiac> e) create our own completely custom theme.

[09:22:53 CDT(-0500)] <anastasiac> eol

[09:48:46 CDT(-0500)] <Justin_o> cindyli: started getting in my changes, i've also merged in yours. so far I've just updated utils.py and added unit tests for it.. next i'll get the fsDictionary and tests for it in place

[09:49:09 CDT(-0500)] <cindyli> that's great, thanks, Justin_o

[09:49:09 CDT(-0500)] <Justin_o> cindyli: thanks for move the resource source tests and for creating a test.py file there too

[09:49:16 CDT(-0500)] <cindyli> np

[10:32:10 CDT(-0500)] <colinclark> alexn1: I updated my comment with a code sample for you

[10:32:12 CDT(-0500)] <colinclark> just refresh

[10:32:28 CDT(-0500)] <alexn1> yeah I see but I still trying to understand the faulty case

[10:32:43 CDT(-0500)] <colinclark> The point is that it's one line of code

[10:32:48 CDT(-0500)] <colinclark> so you can only break before or after that line of code

[10:32:57 CDT(-0500)] <colinclark> yet that line of code does several distinct operations

[10:32:58 CDT(-0500)] <alexn1> I mean I had so many cases when one of the var statements would be a faulty one and I could successfully to break point

[10:33:05 CDT(-0500)] <alexn1> ok standup time

[10:33:05 CDT(-0500)] <colinclark> any one of which you might want to stop and debug

[10:33:10 CDT(-0500)] <alexn1> be right back

[10:33:12 CDT(-0500)] <colinclark> It's just like chaining in jQuery

[10:44:14 CDT(-0500)] <colinclark> Wow, huge Connect fail

[10:45:27 CDT(-0500)] <colinclark> My standup update, fluid-everyone: Really great planning meeting with Michelle, James and Jess regarding Floe 3, and we'll keep those going until the roadmap is looking solid. Some GPII work related to the upcoming matchmaker meeting. Today I'll be talking with a design student candidate, and will try to make some headway on more Video Player pull requests.

[10:47:28 CDT(-0500)] <colinclark> anastasiac: Which document will I find the sections-C3 and C11-that you refer to for the Cloud4all use cases?

[10:54:44 CDT(-0500)] <anastasiac> colinclark, the email I forwarded has two attachments from Maria. The D101.2 document contains the use cases, as well as the chapter 3 that I was thinking you might be able to look at (Maria references the sections in her email)

[10:55:17 CDT(-0500)] <anastasiac> If you want, I can forward you the edits I've done to C3 and C11, but I didn't want to bug you with that if I didn't have to. I just wasn't sure what to do with the sections in chapter 3, colinclark

[10:55:27 CDT(-0500)] <colinclark> thanks

[10:55:30 CDT(-0500)] <colinclark> i'll take a quick look

[10:57:40 CDT(-0500)] <colinclark> Justin_o: You mentioned "extending Python's Dictionary" at standup today

[10:57:45 CDT(-0500)] <colinclark> I was intrigued

[10:59:33 CDT(-0500)] <Justin_o> colinclark: hello.. yes.. i'm trying to do this so we can more seamlessly work with persistent dictionaries/json files

[10:59:43 CDT(-0500)] <colinclark> what does it mean?

[10:59:54 CDT(-0500)] <colinclark> I guess I mean, "tell me more"

[11:00:07 CDT(-0500)] <Justin_o> so for example in python you could set a value on a dictionary like d[key] = "value"

[11:00:26 CDT(-0500)] <Justin_o> which will store it in memory.. so in my case, this would also save it to a file on the file system

[11:01:09 CDT(-0500)]

[11:01:13 CDT(-0500)] <Justin_o> and then act on it as normal

[11:01:28 CDT(-0500)] <Justin_o> so extending it.. d["b"] = "b"

[11:01:30 CDT(-0500)] <Justin_o> and etc.

[11:01:36 CDT(-0500)] <Justin_o> colinclark: ^

[11:01:46 CDT(-0500)] <Bosmon> Do people want fire that can be fitted nasally? : P

[11:02:03 CDT(-0500)] <colinclark> lol

[11:02:15 CDT(-0500)] <colinclark> It does sound like you're trying to make two things into one, Justin_o

[11:02:56 CDT(-0500)] <colinclark> I imagine the challenge of persistence, in Python, to the file system, is pretty analogous to the challenge of persistence on the client side, too

[11:03:07 CDT(-0500)] <colinclark> for example, persisting JSON to a server via an Ajax call

[11:03:13 CDT(-0500)] <colinclark> or saving it to local data storage or whatever

[11:03:40 CDT(-0500)] <colinclark> I wonder if an abstraction analogous to our DataSources...

[11:03:48 CDT(-0500)] <colinclark> and/or ChangeApplier might be more suitable?

[11:04:05 CDT(-0500)] <Justin_o> colinclark: not sure i'm following

[11:04:08 CDT(-0500)] <colinclark> Not to suggest that you've got the time to port core framework features from Infusion to Python, to be clear

[11:04:36 CDT(-0500)] <colinclark> Justin_o: Well, isn't this use case pretty much exactly analogous to a component that uses the ChangeApplier to modified a model

[11:04:52 CDT(-0500)] <colinclark> and an associated listener that would take care of the responsibility of persisting the model in some way?

[11:06:16 CDT(-0500)] <Justin_o> colinclark: okay.. so i think i'm starting to understand what you are saying.. instead of it persisting to the file system, it will make a call to something.. to handle persistence

[11:06:27 CDT(-0500)] <Justin_o> so abstract away how that persistence is actually handled

[11:06:28 CDT(-0500)] <colinclark> yup

[11:06:39 CDT(-0500)] <colinclark> back to the basic principle--separating out concerns

[11:07:13 CDT(-0500)] <colinclark> it sounds like instead you're using our old hammer of inheritance, perhaps?

[11:07:16 CDT(-0500)] <Justin_o> colinclark: conceptually that should be pretty easy to change.. meaning that there are few places that actually interact with the persistence..

[11:07:30 CDT(-0500)] <colinclark> it'd be an awful lot easier to test, etc.

[11:07:43 CDT(-0500)] <Justin_o> colinclark: i'm not sure i totally agree with that

[11:07:54 CDT(-0500)] <colinclark> ok

[11:08:13 CDT(-0500)] <Justin_o> colinclark: i sort of want it to be seamless and have a minimal distinction between a typical dictionary and this one

[11:08:36 CDT(-0500)] <Justin_o> so that the user could use, with the exception of init, basically the same syntax to interact with it..

[11:10:25 CDT(-0500)] <Justin_o> colinclark: since this is a built in data type it'd be difficult for me to rewrite the acceptable syntax and maintain it as python upgraded.. not that this will 100% prevent those issues

[11:10:35 CDT(-0500)] <colinclark> So what is an FSDict, biologically speaking?

[11:10:47 CDT(-0500)] <Justin_o> colinclark: i suppose you could argue that it doesn't have to mirror the syntax though

[11:11:28 CDT(-0500)] <colinclark> It really does seem like persistence is a separate type of behaviour from the Dictionary

[11:11:29 CDT(-0500)] <Justin_o> colinclark: it's basically exactly a dictionary with the exception of creation, and deleting and adding to it

[11:11:36 CDT(-0500)] <colinclark> so it's a subclass?

[11:11:40 CDT(-0500)] <Justin_o> oh yes

[11:12:37 CDT(-0500)] <Justin_o> basically just added to some of the default functions, so init takes in the filepath, and additions, deletions, will save to the file

[11:13:02 CDT(-0500)] <Bosmon> Justin_o - I argue that such a "dictionary" is "unJSONlike"

[11:13:24 CDT(-0500)] <Bosmon> Especially since this now means that changes at the top level version of the dictionary will behave differently to changes at nested paths

[11:13:37 CDT(-0500)] <Justin_o> Bosmon: hmm.. not sure i understand that

[11:13:49 CDT(-0500)] <Bosmon> This is one amongst many reasons why the traditional "inheritance-based instrumentation" approach to persistence is generally faulty

[11:13:50 CDT(-0500)] <Justin_o> what do you mean by behave differently

[11:14:07 CDT(-0500)] <Bosmon> Justin_o - writing to the top level dictionary will trigger a save, writing to any nested dictionary will not

[11:14:32 CDT(-0500)] <Bosmon> Since under the so-called "object-oriented style" any change to nested values will not be detectable by the intrusively modified dictionary at the root

[11:15:01 CDT(-0500)] <Bosmon> My suggestion is that you just return to issuing standard calls to write the dictionary at points whenever you feel it should get written : P

[11:15:41 CDT(-0500)] <Justin_o> Bosmon: so if i'm understanding you correctly, you are saying that because someone can go modify the file on the filesystem directly, there is a problem?

[11:16:20 CDT(-0500)] <colinclark> I think it's more a question of what happens when you have Dictionaries inside a Dictionary

[11:16:22 CDT(-0500)] <Bosmon> Justin_o - nothing to do woth that, no

[11:16:27 CDT(-0500)] <colinclark> are they FSDicts or regular Dictionaries

[11:16:33 CDT(-0500)] <colinclark> and what's the semantic for saves in that case?

[11:16:42 CDT(-0500)] <colinclark> is that about right, Bosmon?

[11:16:51 CDT(-0500)] <Bosmon> Right, colinclark

[11:17:33 CDT(-0500)] <Justin_o> Bosmon, colinclark: I hope you don't think i'm changing the semantics of every dictionary that we could possibly use in our application

[11:17:52 CDT(-0500)] <Justin_o> i'm not doing something like changing the prototype in javascript

[11:18:07 CDT(-0500)] <Bosmon> Justin_o - yes

[11:18:09 CDT(-0500)] <Bosmon> We understand

[11:18:17 CDT(-0500)] <Justin_o> you should be able to put anything that a dictionary would normally take without effect

[11:18:26 CDT(-0500)] <Justin_o> so if you wanted to put in a normal dictionary you could

[11:18:30 CDT(-0500)] <Bosmon> And it's precisely because you can't/don't do that, that the benefit from the FSDict approach seems minimal

[11:18:49 CDT(-0500)] <Bosmon> All you have built now is "a dictionary with irregular persistence semantics over its space of keys"

[11:19:00 CDT(-0500)] <Bosmon> In that the user has to remember that top-level keys behave differently to the other ones

[11:19:07 CDT(-0500)] <Justin_o> i suppose what you are worried about is if i put in a FSDict into an FSDict and then change the nested one with a call from the parent?/

[11:19:15 CDT(-0500)] <Bosmon> No, we don't worry about it!

[11:19:19 CDT(-0500)] <Bosmon> Since you can't do it

[11:19:23 CDT(-0500)] <Bosmon> With any beneficial result

[11:20:20 CDT(-0500)] <Justin_o> Bosmon: hmm.. i'm actually not sure what would happen.. it may work, i suppose it depends on wether it's just consuming the values or using a reference back.. but haven't tried it so have no idea

[11:28:34 CDT(-0500)] <colinclark> Justin_o: That, in itself, should flag a critical issue

[11:28:49 CDT(-0500)] <colinclark> Whereas, if you factor your code into two sections...

[11:28:54 CDT(-0500)] <colinclark> One, just "plain data"

[11:29:09 CDT(-0500)] <colinclark> the other, responsible for the mechanics of persistence, you'll have clear semantics for how it works

[11:29:52 CDT(-0500)] <colinclark> You can, if you wanted to, combine these things into an object you carry around

[11:30:09 CDT(-0500)] <colinclark> representing the persistence-thingy (probably just a save() function or whatever

[11:30:14 CDT(-0500)] <colinclark> 2. the configuration for that

[11:30:19 CDT(-0500)] <colinclark> and 3. the data structure in question

[11:31:41 CDT(-0500)] <colinclark> Presumably it wouldn't be any more inconvenient to carry around and use?

[11:42:37 CDT(-0500)] <Justin_o> colinclark, Bosmon: i'm going to lose what i had hoped for.. which is to have something that looked like a real dictionary

[11:43:09 CDT(-0500)] <Justin_o> i think what you are suggesting is that i build something that maybe uses a dictionary internally, but just expose a simple update method or something similar to that

[11:46:03 CDT(-0500)] <Bosmon> Justin_o - I'm suggesting you just use a plain dictionary

[11:46:11 CDT(-0500)] <Bosmon> And then remember to save it at the right points in time : P

[11:47:39 CDT(-0500)] <Justin_o> Bosmon: yes… that's basically it.. but since i'll be doing this in more than just one place it'd probably make sense to make things as reusable as possible

[11:50:31 CDT(-0500)] <colinclark> Justin_o: Tell me more about what part you want to make "as reusable as possible?"

[11:56:23 CDT(-0500)] <Justin_o> colinclark: okay..so what we need to do in all of the cases where we would currently need to use this.. would be to 1) on init load in / create the persistent data 2) on every update to the dictionary, it would need to be preserved

[12:43:47 CDT(-0500)] <Bosmon> Justin_o - this is why I think it might be a reasonable approach to make a very lightweight mockup of a ChangeApplier

[12:43:52 CDT(-0500)] <Bosmon> It needn't be very complicated at all

[12:44:03 CDT(-0500)] <Bosmon> But just something that controls access to the dictionary as a whole, rather than to just one level of it

[12:44:16 CDT(-0500)] <Bosmon> As colinclark said, there's no need to reimplement all of Infusion

[12:44:24 CDT(-0500)] <Bosmon> But a basic ChangeApplier might be only a dozen lines

[12:48:54 CDT(-0500)] <colinclark> This first code example seems like a reasonable quick way of rolling events for your pyChangeApplierLite http://stackoverflow.com/questions/1092531/event-system-in-python

[12:49:48 CDT(-0500)] <colinclark> completely with fancy Pythonic operator overloading :S

[13:33:30 CDT(-0500)] <kasper_> colinclark: are you there?

[14:21:17 CDT(-0500)] <thealphanerd> colinclark: so are you coming to california for the mentor summit?

[14:21:29 CDT(-0500)] <colinclark> When is it, thealphanerd?

[14:22:04 CDT(-0500)] <thealphanerd> oct 19 - 21

[14:22:23 CDT(-0500)] <thealphanerd> which actually coencides with accessibility camp LA and ycombinators start up camp

[14:22:31 CDT(-0500)] <colinclark> Man, I wish I could

[14:22:38 CDT(-0500)] <colinclark> Let me see how the calendar goes

[14:22:49 CDT(-0500)] <colinclark> I'm traveling a lot in October

[14:46:57 CDT(-0500)] <thealphanerd> fair enough

[14:47:02 CDT(-0500)] <thealphanerd> you can only do what you can

[14:58:54 CDT(-0500)] <jessm> anastasiac: ping

[15:03:24 CDT(-0500)] <anastasiac> jessm, pong

[15:07:29 CDT(-0500)] <jessm> anastasiac: 2 things...

[15:07:53 CDT(-0500)] <jessm> 1. can you send your email re: idi wiki to the list?

[15:08:09 CDT(-0500)] <anastasiac> sure

[15:10:06 CDT(-0500)] <jessm> anastasiac: 2. re: the wiki and templates – let's switch to an out-of-the boxer and go from there – sound good?

[15:10:36 CDT(-0500)] <anastasiac> jessm, sounds good to me. It will look different than what we have now, but I can try to keep it as familiar as possible

[15:11:21 CDT(-0500)] <anastasiac> jessm, should I just go ahead and change it (and risk weirdness while I work on it), or should I checks with avtar about a workspace I can test in first?

[15:11:54 CDT(-0500)] <jessm> anastasiac: that's a good question. I don't know!

[15:11:59 CDT(-0500)] <jessm> it seems pretty bad now

[15:12:07 CDT(-0500)] <jessm> can it be reverted if it makes it worse?

[15:12:29 CDT(-0500)] <anastasiac> I would imagine so… let me double-check something

[15:13:04 CDT(-0500)] <anastasiac> jessm, I'm pretty sure I could revert if it's horrible

[15:13:25 CDT(-0500)] <anastasiac> perhaps I should send an email to the list warning that there will be some changes in the UI

[15:13:36 CDT(-0500)] <jessm> anastasiac: always a good plan

[15:56:48 CDT(-0500)] <alexn1> colinclark: I resubmit my pull request with the changes to address the issues you pointed out. https://github.com/fluid-project/videoPlayer/pull/58

[15:59:00 CDT(-0500)] <anastasiac> jessm, wiki has been updated. please have a look, let me know if you find any problems

[19:56:22 CDT(-0500)] <sgithens> Bosmon: Duadu

[20:55:46 CDT(-0500)] <Bosmon> SWGITHEN!!