[13:07]  * benji does the I-finally-fixed-the-missing-bundle-from-search-bug dance.  It's not pretty.
[13:07] <gary_poster> awesome benji.  what was story
[13:09] <benji> gary_poster: I don't know how it happened, but the checkout of the bundle branch was updated to revno 2 (there are three revisions total) and the charmworld code looks at the number of revisions in the checkout vs the branch to decide if it needs to update the local checkout, since the local checkout has 3 (but is at 2) and the remote branch has 3 it decided there was nothing to do
[13:09] <gary_poster> benji, oh, weird
[13:10] <benji> it just so happened that revno 2 wouldn't pass proof so nothing would get loaded into the db or ES, but at some point in the past revno 3 had been loaded into the db (and perhaps ES as well, but had been perged from there)
[13:10] <gary_poster> interesting
[13:10] <benji> I will make a charmworld branch that will keep this from happening again.
[13:11] <gary_poster> is there some way to prevent that in the future?  I'm guessing we were using bzr revno or equivalent already, and that was what was broken, somehow?
[13:11] <gary_poster> sounds like answer to my first question is "yes" then :-)
[13:11] <benji> :)
[13:35] <rick_h__> benji: woot!
[13:35] <benji> :)
[13:36] <rick_h__> benji: hmm, wonder if when we wiped ES during the great crash that it caused that to happen
[13:36] <rick_h__> only recent time of a greast ES purge lately
[13:36] <rick_h__> well, until all this
[13:36] <benji> we should just put an ES purge in cron, it would simplify things
[13:37] <rick_h__> heh, es-update turns into a "we can nuke it...and rebuild it"
[13:40] <gary_poster> hazmat, hi.  are we doing the UX catchup, with luca unavailable today?  won't be much of a UX catchup without him
[13:45] <gary_poster> https://floobits.com/ : looks potentially awesome for pairing (real-time collaboration across emacs, vim, sublime text, and browser-based editor) once it's working on SublimeText/Linux (https://github.com/Floobits/floobits-sublime/issues/96)
[13:45] <gary_poster> note that one person can be using vim and other person can be using sublime text simultaneously, for instance
[13:58] <hazmat> gary_poster, i was planning on it.. ale requested.. will leave up to her
[14:00] <gary_poster> hazmat, oh ok.  thx.  May ask Jeff and/or Matt to attend if it seems like meeting is going in a direction where it would be useful for them
[14:01] <BradCrittenden> rick_h__: thanks for the review
[14:02] <bac> benji: i just discovered ingest waits a full 15 minutes between finishing and starting again if --run-forever is used.  dopey.
[14:02] <benji> pfft
[14:03] <benji> that might put a damper on throughput
[14:03] <rick_h__> bac: sorry, qa is taking a second, proof is blowing up. A bundle by jamespage isn't getting loaded and proof seems to have syntax/json issues right now
[14:03] <bac> rick_h__: np
[14:03] <rick_h__> benji: gary_poster heads up that proof goes boom currently ^
[14:04] <benji> rick_h__: k
[14:04] <gary_poster> :-( ack
[14:04] <benji> rick_h__: do we fail open or closed?
[14:04] <bac> benji: yeah, so the queue cronjob gets to run every 15 minutes but ingest runs much slower since time to run isn't considered
[14:08] <rick_h__> benji: not computing atm. Right now proof has a syntax error and the current proof call from the cli is getting a 500 back from mjc. I'm trying tomanually form the proof call to see if someting in the bundle causes us to 500 or if proof itself is building a bad request
[14:09] <benji> rick_h__: my intent was learn whether we reject all when proof fails or let all through when it fails.  I hope we reject everything.
[14:10] <rick_h__> benji: we should be doing whatever we do with charms I believe. I'm not 100% sure. We don't get it in the store but can't speak if it's that half 'I know it's there but don't show it' business 
[14:10]  * rick_h__ had to go look up fail open/close
[14:10] <benji> :)
[14:13] <hatch> so hows everyones morning?
[14:26] <bac> hatch: i just dropped my yogurt, but until then everything was fine.
[14:26] <hatch> oo ouch
[14:29] <gary_poster> probably more like squish than ouch
[14:33] <bac> splat and splurt.  landed on its side, open, and disgorged half the contents.  luckily i didn't step in it.
[14:34] <hatch> I wonder how one decides between a splat and a splurt
[14:34] <gary_poster> pure sound, I'd guess
[14:39] <hatch> anyone know how to debug this http://askubuntu.com/questions/393371/juju-gui-problem-with-login ?
[14:40] <hatch> in other news, clojure is a nice looking language https://github.com/swannodette/todomvc/blob/om/labs/architecture-examples/om/src/todomvc/app.cljs
[14:40] <hatch> purely visual, I have no idea what it's doing :D
[14:40] <rick_h__> lol
[14:41] <hatch> I'm really not sure how all of these clojure > js compilers enforce immutability "with no cloning" 
[14:42] <rick_h__> hatch: you have to get into clojure data types
[14:42] <benji> I like lisps, and Om sounds like it is well thought out.
[14:42] <rick_h__> because you're in that language you're using it's methods of things which is performing the operations for you in JS
[14:42] <hatch> rick_h__ well i'm thinking purely from the javascript side
[14:42] <hatch> you either clone the object, or remake it....not much getting around that
[14:42] <rick_h__> right, but you never touch/look at the JS
[14:42] <hatch> oh so these statements are purely from the libraries point of view
[14:43] <hatch> not the underlying functionality
[14:43] <rick_h__> how I read it but maybe I'm mistaken. I've only looked at closure and not the script side
[14:43] <rick_h__> I can't get past all the () in the lisp stuff 
[14:44] <hatch> jeesh it's a darn good thing you're in the python world lol
[14:44] <rick_h__> I chose python (or it chose me) 
[14:44] <hatch> I'm actually pretty interested in lispy stuff, I'll probably be pending some time over the break giving it a go
[14:45] <rick_h__> I did php, javascript, asp for more than a couple of years before I busted my $#@$#@ to get a job in python
[14:45] <hatch> closure seems like the best candidate
[14:45] <rick_h__> yea, clojure (closure is the google JS framwork)
[14:45] <benji> hatch: the concept the datastructures use is called "persistence" but it's not the "store in a database" kind of persistence.  Referring you to this will save me some typing: http://en.wikipedia.org/wiki/Persistent_data_structure
[14:48] <hatch> benji right, but in js you must clone the object to do that
[14:49] <hatch> so these docs must be referencing the higher level api's in the libraries
[14:50] <benji> hatch: I don't know how ClojureScript is implemented, but you may be right, that or they don't use the JS datastructures at all and can therefore assure true imutability
[14:51] <hatch> yeah clojure :) sorry, I was spelling things properly for once lol
[14:53] <rick_h__> jujugui added a pair of proof bugs for ingesting bundles to the board. One should be small, one medium. Got around mostly to get james's bundle to load work in jujucharms.com, but can't currently be ingested. 
[14:53] <gary_poster> ack thanks.  I saw.  that's been waiting for us.
[14:54] <rick_h__> yea, he built a serious bundle there
[14:54] <rick_h__> openstack-on-openstack 
[14:54] <gary_poster> heh, wow
[14:54] <rick_h__> I think we found our new test bundle :)
[14:54] <gary_poster> awesome :-)
[14:54] <rick_h__> "if that works then $#@$#@ everything better work"
[14:54] <gary_poster> lol
[14:55] <hatch> haha
[14:55] <bac> rick_h__: does this mean my qa is doa?
[14:56] <rick_h__> bac: no, it means I'm just now getting to it
[14:56] <rick_h__> the fire is in control on the james side. 
[14:56] <rick_h__> bac: sorry for the delay
[14:57]  * rick_h__ needs to learn to let irc be more :)
[14:57] <bac> rick_h__: thx
[14:58] <hatch> rick_h__ "Should proof as valid"
[14:58] <hatch> ;)
[14:58] <bac> 'tis the season...
[14:58] <rick_h__> hatch: sssh it's friday
[14:58] <bac> to shout in a bullhorn
[14:58] <hatch> haha
[14:59] <bac> this week we've had noisy protests from dairy farmers and teachers and now the bus drivers are on strike
[14:59] <rick_h__> bac: I changed grocery stores for the last bit because I got sick of the bell outside of the closest one
[14:59] <rick_h__> ugh
[14:59] <hatch> oh d3
[15:03] <hatch> I MIGHT have found a clean way to write d3 code
[15:04] <hatch> the linter probably won't like it
[15:04] <hatch>     relationWrapper.append('h4')
[15:04] <hatch>                    .text(function(d) { return 'Interface: ' + d.interface; });
[15:04] <hatch> well that didn't work
[15:04] <Makyo> Yeah, the linter kinda hates chaining/.
[15:06] <hatch> and I'm with it
[15:06] <hatch> haha
[15:06] <rick_h__> bac: are there qa instructions? From where my db is I can't upgrade I get an error that : Exodus index "charms_pending_019" does not exist.
[15:07] <rick_h__> bac: and in looking around the migrate stuff has changed a bunch and not sure if I should be able to upgrade from current state or have to do a reset?
[15:07] <hatch> annnnnnd relations tab has been converted to d3
[15:07] <hatch> now to cssify it
[15:07] <rick_h__> bac: and the makefile has no migrate commands any more :/
[15:07] <bac> rick_h__: i thought there used to be makefile support for migrate stuff.  boo.
[15:08] <bac> rick_h__: you want to chat?
[15:08] <rick_h__> bac: sure
[15:08] <rick_h__> bac: https://plus.google.com/hangouts/_/7ecpiqltgarlsn4gsp09jd6i2c?hl=en
[15:39] <hatch> holy itunes is such a garbage app
[15:50] <hatch> jujugui call in 10
[15:50] <gary_poster> ty
[15:58] <gary_poster> jujugui call in 2
[16:00] <gary_poster> benji Makyo ping
[16:48] <hatch> rick_h__ I have a blog post I wrote a while ago on TDD that people have said has been really helpful
[16:48] <hatch> I think it helps answer some of your issues
[16:49] <rick_h__> hatch: linky, I'm happy to look. My point was less in theory though and what I tend to run into in practice
[16:49] <rick_h__> in theory pure TDD seems great, but in practice you end up really needing a first prototype like gary_poster mentioned to get an idea of what it should look like first
[16:50] <rick_h__> and then go back at it, but by then you've put some pre-thought more into things than without a prototype. If you sit down to add feature X to the browser and just start TDD'ing I find that really often the code api is horrible 
[16:50] <gary_poster> I think TDD embraces that, or at least some/many practitioners do
[16:50] <rick_h__> and maybe I've just had really bad experience with it :)
[16:51] <rick_h__> yea, the post-refactor should help some, so I don't really have issues with the full pure TDD in theory. 
[16:51] <gary_poster> That is, you can do TDD without prototyping, but you can still call it TDD with it
[16:51] <rick_h__> ah, yea 
[16:51] <hatch> http://fromanegg.com/post/54890090207/test-driven-development-the-easy-way
[16:53] <rick_h__> hatch: yea, this kind of fits in with what I'm saying. I really find I like to sit down and work out 'what is the code I want to write to make feature XX happen'
[16:53] <rick_h__> and then write that with TDD, but establish most of an 'api' first
[16:53] <hatch> well the TDD is supposed to help you design the api
[16:53] <hatch> if you need these X things to happen you need at least X functions
[16:53] <hatch> because a function should only have a single role
[16:54] <hatch> (in a perfect world)
[16:54] <hatch> it also then helps you prototype because you can use the test to send a datastructure to that function
[16:54] <hatch> so you can iterate very fast
[16:55] <hatch> TDD is hard to do because we just want to get in there and DO something :D
[16:55] <hatch> I suppose that's BDD? heh
[16:57] <hatch> gary_poster would you say that clojure is a good language to learn to get a better understanding of these persistent data structure ideas? 
[16:57] <benji> rick_h__: If you want a different perspective, I really like documentation-driven development (especially for libraries, but I consider almost everything a library even if it only has one user)
[16:58] <benji> this guy's writing states it pretty well: http://tom.preston-werner.com/2010/08/23/readme-driven-development.html
[16:58] <hatch> TDD, BDD, DDD
[16:58] <hatch> how many DD's are there? heh
[16:59] <benji> but I think it should be taken one step further: your documentation should be tested so that it isn't lying about the code (https://pypi.python.org/pypi/manuel/)
[16:59] <hatch> just write Go with godoc then ;)
[17:01] <benji> even better than DDD, I like ZDD (zealot-driven development)
[17:01] <rick_h__> woot! how can I sign up for that
[17:01] <benji> hatch: godoc doesn't let you have a real naritive structure, think more like literate programming, but literate tests
[17:02] <hatch> :)
[17:02] <hatch> Makyo got a second to look at some d3 code? https://gist.github.com/hatched/5466e333d47b7b459486 
[17:02] <benji> rick_h__: I'm not kidding, if a group of people really like something (a language, a library, a methodology) it is a good way for the group to be very productive
[17:02] <rick_h__> I think I'm feeling like I'm missing something though because many of the quickstart reviews I've had a hard time with. 
[17:03] <rick_h__> though it seems a LOT of design/discussion has gone into them ahead of time 
[17:03] <Makyo> hatch, sure.
[17:03]  * benji stops talking about this before he suggests regex-driven-development.
[17:03] <rick_h__> so I'll get back to going through the functional JS book and see if I can open my brain up a bit more, but man sometimes I can't help but think what a different version would be written like
[17:03] <hatch> the unitlist exit isn't working....just wondering if there is something obvious I'm missing
[17:03] <hatch> line 71
[17:06] <Makyo> hatch, try storing the enter in a different variable.  line57: var units = unitList.enter(); units.append [...]
[17:06] <hatch> the unit property is entirely going away as well, think that could be it
[17:07] <hatch> so line 52 would return undefined
[17:07] <hatch> I can try the new var though
[17:07] <Makyo> Oh, hm.
[17:09]  * Makyo goes through expenses, sheepishly submits three items :(
[17:09] <hatch> yeah that didnt help so it must be that units is undefined when there are no unit errors
[17:09] <hatch> so I'll leave that as an empty array
[17:09] <Makyo> Oh, okay.
[17:09] <Makyo> Yeah, that makes sense.
[17:14] <hatch> hmm ln 111 is throwing a d3 .length error...I might need to use filter there
[17:15] <Makyo> There is no line 111.  Options are filter or empty array, seems like.
[17:15] <Makyo> why not return d.units || [] or something?
[17:18] <hatch> the data structure not has units as an empty array 
[17:19] <hatch> but line 51 is throwing the error sorry
[17:19] <hatch> my guess is that the selectAll is returning undefined
[17:20] <hatch> so it can't call length on it
[17:23] <Makyo> Can break and run it in isolation?
[17:23] <Makyo> selectAll should return an empty array.
[17:24] <hatch> cool got it working
[17:24] <hatch> man you're a good rubber duck
[17:24] <hatch> :P
[17:26] <hatch> Makyo is there a way to debug things like these select and selectAll calls? 
[17:26] <hatch> besides console logging their output?
[17:27] <hatch> I'm hoping for some kind of debugger; injection :)
[17:28] <Makyo> Debugger line 48, relationWrappers is now in scope in the console. Don't know what else you need.
[17:29] <hatch> well say I wanted to keep the chaining going but inspect the data as it progresses through each step
[17:29] <hatch> I could assign each to a variable of course but that's kind of a lot of work :)
[17:30] <Makyo> You were given an up-arrow and console history for a reason :)
[17:30] <Makyo> do the .select(), then uparrow and add the .selectAll()
[17:30] <hatch> ohhhhh kayyy
[17:30] <Makyo> Given that the debugger works differently depending on browsers, actual injection would be kind of huge.
[17:40] <hatch> yeah
[17:40] <hatch> a guy can dream I suppose :)
[18:02] <hatch> make lint......kaboom!
[18:23] <frankban> Makyo: EOD for me, time to go. I know you are already busy mon and tue, so, the following is just for reference: my current branch is in lp:~frankban/juju-quickstart/env-manage-edit . it's almost done (some tests missing). If you want to take a look, good, if not good again, and I'll finish the work on Jan.
[18:24] <Makyo> frankban, Cool, I'll pick it up next week pending this branch.
[18:24] <gary_poster> frankban, happy holidays!
[18:24] <Makyo> James' brake calipers froze, going to get him to the shop in a few over lunch, will be afk during.
[18:25] <frankban> cool, thank you gary_poster, you too! happy holidays everyone!
[18:25] <gary_poster> ack
[18:25] <gary_poster> :-)
[18:25] <hatch> anyone available for a quick pre-test-writing review?
[18:25] <gary_poster> happy holidays to everyone in jujugui.  I'll see a couple of you Monday.  I'm going to go lie down
[18:25] <hatch> frankban merry christmas!
[18:25] <Makyo> Cheers.  Happy merry.
[18:25] <hatch> lol
[18:25] <frankban> :-)
[18:26] <hatch> Makyo might have jumped into the sauce a little early
[18:26] <benji> gary_poster: Merry Christmas and a Happy New Year!
[18:26] <Makyo> Hah!
[18:26] <hatch> https://github.com/hatched/juju-gui/compare/juju:develop...hatched:relation-unit-errors?expand=1
[18:27] <hatch> ^ Makyo wana take a quick peek? 
[18:27] <Makyo> Sure.
[18:27] <hatch> thanks
[18:28] <hatch> The tests aren't in that of course but just want to make sure you agree with the code before I write them 
[18:33] <Makyo> That seems reasonable, yeah.
[18:33] <hatch> kewlio
[18:34] <hatch> now to lunch
[18:47]  * Makyo runs away to help James.
[18:59] <bac> benji: thanks for the qa-ing
[18:59] <benji> np
[20:40]  * bac walks dog between downpours