=== Makyo is now known as Makyo|out
=== gary_poster is now known as gary_poster|away
=== teknico_ is now known as teknico
[13:01] <rogpeppe> bac: ping
[13:02] <bac> hi rogpeppe
[13:02] <rogpeppe> bac: we've just been debating the yaml parameter to the service set command
[13:02] <bac> rogpeppe: i *just* got my new 64 bit environment to work and successfully bootstrapped.  was just starting to look at your work from yesterday.
[13:02] <rogpeppe> bac: how important is it to the gui that the user be able to enter yaml parameters
[13:02] <rogpeppe> bac: cool!
[13:03] <bac> rogpeppe: quite important for us to support the upload of a service configuration file
[13:04] <bac> rogpeppe: the UX guys have spent a lot of time getting the design of the file upload right in the GUI so i know they consider it very important
[13:05] <rogpeppe> bac: ok, that's useful, thanks
[13:05] <bac> np
=== gary_poster|away is now known as gary_poster
[13:09] <Guest47530> hmm, all of my windows have gone black and white, that's a new one
=== Guest47530 is now known as benji
[13:12]  * benji reboots.
[13:25] <gary_poster> Hi therve.  Thanks for the mail.  The duplication that you eliminated is in the annotations alone, right?  The resulting URLs are essentially untouched.  That is, a service URL is https://host/account/standalone/computers/criteria/environment:env_uuid+service:service0 and a unit URL is https://host/account/standalone/computers/criteria/environment:env_uuid+unit:service0%02F0 
[13:26] <therve> gary_poster, correct
[13:26] <therve> the value for environment: changed too
[13:27] <gary_poster> therve, just because of the UUID instead of the internal name, right?  In terms of assembling URLs from the annotations, the pattern is the same
[13:28] <gary_poster> (and the size of the annotation)
[13:28] <therve> gary_poster, yep that's right
[13:28] <gary_poster> Cool, sounds good therve.  Thanks.
[13:28] <therve> no problem, thank you!
[13:33] <gary_poster> bcsaller_, morning.  I'll re-review your TARDIS branch in just a few.  Meanwhile, though, for your other active card, the ground shifted slightly beneath you.  I don't think it should be too bad to adjust, hopefully.  Could you take a look at the first comment in https://bugs.launchpad.net/juju-gui/+bug/1126249 and let me know if you have any questions or concerns?
[13:33] <_mup_> Bug #1126249: functions/methods to calculate Landscape links for units, services, environment <juju-gui:Triaged> < https://launchpad.net/bugs/1126249 >
[13:47] <bcsaller_> gary_poster: checking it now
[13:51] <bcsaller_> gary_poster: I don't think there are any serious issues 
[13:54] <benji> rogpeppe: the websocket is connected to port 17070, right?  I as because I am getting wierd (non-HTTP-like) results when connecting to that port
[13:55] <rogpeppe> benji: yeah, i think so
[13:55] <rogpeppe> benji: yes, 17070 it is
[13:55] <rogpeppe> benji: and it's https (well, wss)
[13:56] <gary_poster> cool bcsaller_ thanks.  Re TARDIS branch, I might propose a branch or diff with suggested doc additions.  Would that be ok?
[13:56] <benji> rogpeppe: oh! maybe that's it; I didn't expect the connection to be encrypted.  Thanks, I'll look at that.
[13:56] <bcsaller_> gary_poster: yeah
[13:56] <gary_poster> cool
[13:56] <rogpeppe> benji: cool.
[13:57] <benji> rogpeppe: it worked!  thanks
[13:57] <rogpeppe> benji: lovely
[14:04] <gary_poster> frankban, hi.  Does charm bug 1130681 make sense to you? I have never seen this problem, so my question for him is why, or under what circumstances, does he hace /usr/lib/juju in the sys.path.  I'm assuming he means that /usr/lib is his working directory, but I don't know when that would occur
[14:04] <_mup_> Bug #1130681: Import error in api service <juju-gui:New> < https://launchpad.net/bugs/1130681 >
[14:04] <hatch> morning
[14:04] <gary_poster> morning hatch
[14:04] <frankban> gary_poster: looking
[14:05] <gary_poster> thanks
[14:08] <frankban> gary_poster: hum, I agree with you, we need more context on that bug
[14:08] <gary_poster> ok thanks frankban I will follow up
[14:08] <goodspud> gary_poster, thanks for you comments on the wires yesterday
[14:09] <gary_poster> Welcome goodspud.  Maybe not helpful, but at least you know someone is still breathing on the other end of the phone :-)
[14:09] <goodspud> gary_poster, :)   Any comments are helpful.... my mantra
[14:09] <gary_poster> :-)
[14:11]  * hatch has a very sore throat so he probably won't be talking much :/
[14:11] <gary_poster> :-( take it easy
[14:12]  * gary_poster has been up since 3:30 when the baby cried, so he probably won't be thinking much :-/
[14:12] <hatch> uh oh!
[14:41] <hatch> my mac mini ram upgrade is taking forever! to get here
[14:42]  * hatch needs more rams!
[14:42] <hatch> of course right after I said that it'll probably show up ;)
[14:45] <gary_poster> frankban, Andreas replied.  I don't know why he would have encountered that and we have not.  I'm trying to dupe.
[14:51] <frankban> gary_poster: we never tried with juju-origin: lp:juju. thanks for trying to dupe.
[14:51] <gary_poster> welcome
[14:53] <hatch> very cool video on google glass http://www.youtube.com/watch?v=v1uyQZNg2vE
[14:53] <frankban> rogpeppe: hi, it seems gojuju's juju-log command has a different behavior (compared to pyjuju's one). please see http://pastebin.ubuntu.com/1690685/ . IIUC, '-->' is considered a flag
[14:54] <rogpeppe> frankban: hmm, does pyjuju's log command accept any flags?
[14:55] <frankban> rogpeppe: pyjuju accepts that command and considers '--> Entering...' to be its string content
[14:57]  * rogpeppe tries to understand the python debug-log code
[14:58] <frankban> rogpeppe: in other words, subprocess.call(['juju-log', '--x']) just prints '--x' in pyjuju, and raises that "flag provided but not defined" error in gojuju 
[14:59] <rogpeppe> frankban: hmm, so it's different from all the other commands in that respect.
[14:59] <rogpeppe> frankban: we should follow suite
[14:59] <rogpeppe> suite
[14:59] <rogpeppe> suit
[14:59] <rogpeppe> frankban: got a call, back in a bit
[14:59] <frankban> rogpeppe: sure, thanks
[15:01] <benji> frankban: were you guys able to log in via the websocket API?
[15:01] <frankban> benji: yes, user "user-admin", arbitrary password
[15:02] <gary_poster> biab
[15:02] <benji> frankban: how does the JSON document look?  Is there a branch that I can crib from?
[15:02] <frankban> benji: in the future I believe the password will be the admin-secret.
[15:03] <frankban> benji: juju-gui trunk, we implemented the authentication in the go environment
[15:03] <benji> cool!  I'll take a look.
[15:03] <bac> benji: congrats on getting the ws to talk
=== Makyo|out is now known as Makyo
[15:30] <benji> bac: how did you get juju-core to rebuild?
[15:30] <Makyo> guihelp call?
[15:31] <bac> benji: er?
[15:31] <gary_poster> jujugui please have call without me.  
[15:31] <Makyo> gary_poster, ack
[15:31] <gary_poster> house leak and rotted subfloor yay!
[15:31] <teknico> uh?
[15:31] <benji> yow :(
[15:31] <teknico> really?
[15:31] <bcsaller_> sounds awful
[15:32] <bac> benji: call?
[15:33] <benji> bac: I have to install the Google video plugin first
[15:51] <hatch> ugh I accidentally chowned my whole /bin dir
[16:08] <bcsaller_> pwned
[16:08] <hatch> yeah who feels like an idiot now....
[16:08] <hatch> <---- this guy
[16:11] <hatch> at least I did that on my laptop so hopefully I can boot up into debug mode (or whatever it's called) and change sudo back
[16:23] <rogpeppe> frankban: actually, i believe that juju-log --x will fail in py juju too
[16:24] <rogpeppe> frankban: from my experiments, if you'd done 'juju-log "-->entering"', that would fail too
[16:24] <rogpeppe> frankban: but it will succeed with a space before "entering"
[16:25] <rogpeppe> frankban: i have mixed feelings about whether we want to duplicate this subtle and somewhat error-prone behaviour in the Go version.
[16:26] <frankban> rogpeppe: hum, weird, the juju gui charm works well in python logging "--> Enetering". anyway, we are trying to work around this issue. 
[16:27] <rogpeppe> frankban: yeah, that will work, as the argument has a space in it
[16:27] <rogpeppe> frankban: but "-->Entering" would have failed
[16:27] <frankban> rogpeppe: but not in juju-core, right?
[16:28] <rogpeppe> frankban: yeah, in juju-core too - it parses command line options like gnuflag
[16:28] <rogpeppe> frankban: except maybe i missed that wrinkle
[16:28] <rogpeppe> frankban: nope, it's a python argparse thing
[16:29] <rogpeppe> frankban: if in doubt, you can log with juju-log -- '--> Entering'
[16:29] <rogpeppe> frankban: (the -- marks the end of flag processing)
[16:30] <frankban> cool rogpeppe, ok. so rogpeppe  and gary_poster: we should update the charm tools: see http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/helpers/python/charmhelpers/__init__.py#L51
[16:31] <frankban> for now we will just avoid calling log_entry and log_exit
[16:31] <frankban> we decided to write a context manager that should allow for doing the same in a easier way
[16:31] <rogpeppe> frankban: yeah. sigh, i'll raise a bug and we'll see what the right resolution is
[16:32] <frankban> rogpeppe: thanks a lot
[16:36] <benji> rogpeppe: how do I rebuild after modifying the code?
[16:37] <rogpeppe> benji: "go test" will rebuild and run tests
[16:37] <benji> % go test
[16:37] <benji> can't load package: package .: no Go source files in /home/benji/workspace/juju-core/trunk
[16:37] <rogpeppe> benji: you can check if something builds with "go build" (rarely used) or "go install"
[16:37] <rogpeppe> benji: ah, go test ./...
[16:37] <benji> % go test ./
[16:37] <benji> can't load package: package .: no Go source files in /home/benji/workspace/juju-core/trunk
[16:37] <benji> oh, ellipsis
[16:38] <rogpeppe> benji: or if you're in the directory of the package you've changed, "go test" tests the current directory
[16:38] <rogpeppe> benji: "go install ./..." will build and install everything under the current directory
[16:39] <rogpeppe> benji: in general, the go command operates on the package in the current directory, but you can give it a list of package names to operate on
[16:39] <benji> thanks, I was missing the ellipsis
[16:39] <rogpeppe> benji: np. it's a general pattern-matching wildcard BTW
[16:40] <rogpeppe> benji: try "go help packages" for more info
[16:40] <benji> rogpeppe: on an unmodified trunk I get lots of errors, is that expected?
[16:40] <rogpeppe> benji: nope
[16:40] <rogpeppe> benji: paste?
[16:42] <benji> rogpeppe: http://paste.ubuntu.com/1691147/
[16:43] <rogpeppe> benji: hmm, what revision are you at?
[16:44] <benji> I have no idea.  I'll update and see if anything changes.
[16:44] <rogpeppe> benji: ah, i see your problem
[16:44] <rogpeppe> benji: you're not using GOPATH
[16:44] <benji> % echo $GOPATH
[16:44] <benji> /home/benji/workspace/go
[16:44] <gary_poster> frankban, ack.  looks like line 45 of http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/helpers/python/charmhelpers/__init__.py#L45 would be best fix--that is, the log command should insert "--".  Do you agree?
[16:44] <rogpeppe> benji: your branch should be at /home/benji/workspace/go/src/launchpad.net/juju-core
[16:45] <rogpeppe> benji: not /home/benji/workspace/juju-core/trunk
[16:45] <benji> % ls /home/benji/workspace/go/src/launchpad.net/juju-core
[16:45] <benji> cert   cloudinit  contrib       doc         environs  LICENCE  README  schema  store    thirdparty  upstart  worker
[16:45] <gary_poster> And yes, water damage from washing machine.  Laundry room and into kitchen.  We though it was seasonal expansion of boards but it is water damage.  Hopefully insurance is ok with it.
[16:45] <benji> charm  cmd        CONTRIBUTING  downloader  juju      log      rpc     state   testing  trivial     version
[16:45] <gary_poster> Will mean a lot of money, I expect.
[16:45] <hazmat> gary_poster, ouch
[16:45] <frankban> gary_poster: agreed, that should fix the problem
[16:45] <gary_poster> ok cool frankban 
[16:45] <gary_poster> yeah hazmat :-(
[16:46] <rogpeppe> benji: what's your cwd (the directory you ran the go build command from) ?
[16:46] <hazmat> gary_poster, frankban re charm... ls folks noticed some breakage if juju-origin: branch
[16:46] <benji> % pwd
[16:46] <benji> /home/benji/workspace/juju-core/trunk
[16:46] <rogpeppe> benji: right
[16:46] <rogpeppe> benji: that's not in your GOPATH
[16:47] <gary_poster> hazmat, ack.  I had just determined that it was something on the branch when I had the water damage thing come up
[16:47] <benji> gary_poster: yow!  I hope the insurance works out for you.  We had some water damage (but the fast kind) and our insurance payed for everything
[16:47] <frankban> hazmat: bug 1130681 ?
[16:47] <_mup_> Bug #1130681: Import error in api service <juju-gui:Incomplete> < https://launchpad.net/bugs/1130681 >
[16:47] <gary_poster> hazmat, they filed bug ...yeah that one :-)
[16:47] <gary_poster> and I have duped
[16:47] <hazmat> that's the one
[16:48] <gary_poster> hazmat, how is branch installed?  setuptools?
[16:48] <rogpeppe> frankban: https://bugs.launchpad.net/juju-core/+bug/1130771
[16:48] <_mup_> Bug #1130771: juju-log is not compatible with python version <juju-core:New> < https://launchpad.net/bugs/1130771 >
[16:48] <gary_poster> that was my guess as to underlying cause for the difference when I was thinking about it
[16:48] <benji> rogpeppe: same problem after adding it to my GOPATH (which now reads "/home/benji/workspace/juju-core/trunk:/home/benji/workspace/go")
[16:48] <frankban> rogpeppe: thanks
[16:49] <gary_poster> thanks benji.  yeah, we'll see.
[16:49] <rogpeppe> benji: i suggest you read this: http://golang.org/doc/code.html
=== goodspud_ is now known as goodspud
[16:50]  * hazmat has been happy with GOPATH=$HOME
[16:50] <rogpeppe> hazmat: yeah, i've been tempted to do that
[16:50] <hazmat> rogpeppe, yeah.. i think i picked up from cheney
[16:51] <benji> rogpeppe: any hints as to which parts I am confused about?
[16:51] <rogpeppe> benji: all packages live somewhere in $GOPATH, under $gopathdirectory/src/$packagepath
[16:52] <hazmat> bcsaller_, ie workspace/juju-core/trunk is suspect
[16:52] <hazmat> whoops for that was for benji
[16:52]  * hazmat curses nick completion
[16:52] <rogpeppe> benji: in your case, the branch needs to be at /home/benji/workspace/go/src/launchpad.net/juju-core
[16:53] <rogpeppe> benji: because your $GOPATH is /home/benji/workspace/go
[16:53] <rogpeppe> benji: if you need several juju-core branches, you can use a recent version of bzr, or cobzr (i use cobzr)
[16:54] <rogpeppe> benji: if you set GOPATH and do "go get launchpad.net/juju-core/cmd/juju" that will do everything for you
[16:54] <rogpeppe> benji: then you can cd /home/benji/workspace/go/src/launchpad.net/juju-core, and manipulate the fetched branch at will
[16:55] <rogpeppe> benji: (it sounds like you'd already done that though)
[16:55] <benji> rogpeppe: I think I see where things are going astray though; thanks for the help
[16:55] <rogpeppe> benji: np
[16:55] <rogpeppe> benji: it's a little different to most conventions, but it works quite well.
[16:56] <hazmat> its actually closer to maven/ivy from java 
[16:58] <gary_poster> frankban, hazmat, mostly confirmed that the branch approach uses easy install to install juju, and that mucks with sys.path so strongly that its paths comes before PYTHONPATH.  In some more perfect world, I'd say that the right solution would be to have the branch install not use easy install.  In this world, I'm inclined to do a hack like the one Andreas described.  The working directory still comes first in the pat
[16:58] <gary_poster> h, thankfully, so we can use that.
[16:59] <gary_poster> I will file a comment and adjust the bug title to reflect the real problem
[16:59] <frankban> gary_poster: +1, thanks
[16:59] <hazmat> gary_poster, ack
[17:00] <hazmat> fwiw, i added a comment noting the issue and a temporary solution for him (ie. use the ppa)
[17:01] <hatch> and /bin recovered....
[17:01] <hatch> note to self - pay attention when you start with `sudo chown -R` ;)
[17:17] <hazmat> ouch
[17:18] <hazmat> has anyone been able to run juju-core test suite without failure?
[17:20] <gary_poster> hazmat I don't think so.  jujugui ^^^ ?
[17:20] <gary_poster> frankban, I filed bug 1130793 fwiw
[17:20] <_mup_> Bug #1130793: For safety, Python charm-helpers juju-log command should insert a "--" before the log message. <Juju Charm Tools:New> < https://launchpad.net/bugs/1130793 >
[17:20] <bac> hazmat: yes, on occassion.  as of a few days ago there were some intermittent failures but it would some times run cleanly.
[17:21] <frankban> gary_poster: cool, contextually we could add the other helpers we have in the gui charm
[17:22] <gary_poster> hatch, thank you for filing those bugs.  please add url to doc in bug report so people can follow along
[17:22] <hatch> sure thing
[17:22] <gary_poster> frankban, +1! 
[17:32] <hatch> bcsaller_: can I move your namespace aware from review? I need to move a ticket in there which will push it over
[17:33] <bcsaller_> hatch: yes, its merged
[17:34] <hatch> ok done!
[17:39] <gary_poster> lunch and more water damage stuff
[17:39] <benji> rogpeppe: if I were to add a method to srvClient how would I bootstrap an environment with that new method exposed via the api?
[17:40] <rogpeppe> benji: use juju bootstrap --upload-tools
[17:40] <benji> rogpeppe: I was afraid you would say that. :) ...because that's what I did.
[17:40] <rogpeppe> benji: ah :-)
[17:41] <rogpeppe> benji: could you paste your copy of apiserver.go ?
[17:41] <benji> rogpeppe: when I attempt to call it I get {"RequestId":1,"Error":"no such request \"Hello\" on Client","Response":{}}
[17:41] <benji> sure, one sec
[17:42] <frankban> rogpeppe: does default-series work? I have precise in my yaml, but nodes are created using quantal
[17:42] <rogpeppe> frankban: hmm, not sure of current status - better ask in #juju-dev
[17:42] <frankban> rogpeppe: ok thanks
[17:43] <benji> rogpeppe: here is the whole file: http://paste.ubuntu.com/1691354/ and here is the diff http://paste.ubuntu.com/1691355/ .  And to be clear, that is the entirety of the change I made.
[17:43] <rogpeppe> benji: ah, the first argument to Hello needs to be the Hello struct
[17:44] <hatch> how does the YUI version get updated? I see it's updated to pr3 already which was just released yesterday :)
[17:44] <rogpeppe> benji: we'd usually name that rpcHello
[17:44] <rogpeppe> benji: oops, that's what you're returning
[17:44] <benji> ah, let me try that
[17:44] <rogpeppe> benji: anyway, any argument needs to be a struct
[17:44] <rogpeppe> benji: (if you *have* an argument)
[17:46] <rogpeppe> i've got to go very soon, and i'm going to be away the next two days
[17:47] <rogpeppe> i should be in sporadic contact via email
[17:47] <rogpeppe> so please email me if you have any issues
[17:47] <benji> rogpeppe: thanks for the help
[17:48] <rogpeppe> benji: np
[17:48] <rogpeppe> benji: hope it goes alright for you :-)
[17:48] <benji> you and me both ;)
[17:51] <rogpeppe> gary_poster: i've proposed the first branch with an API watcher in: https://codereview.appspot.com/7390043/
[18:07] <hatch> Oooo new ram has arrived
[18:11] <hatch> lunch
[18:12] <bac> hazmat: i'm having similar build/install problems as benji.  but my GOPATH seems to be set correctly.  do you see anything funny here: http://paste.ubuntu.com/1691498/
[18:14] <bac> gah, ...
[18:14] <bac> nm
[18:17] <hatch> Boo yeah! 16GB of ram
[18:17] <hatch> VM's do your worst!
[18:45] <Makyo> bcsaller_, ping
[18:46] <bcsaller_> Makyo: whats up?
[18:46] <Makyo> bcsaller_, have five minutes for a quick hangout?  Weird problem.
[18:49] <Makyo> jujugui's open
[18:49] <bcsaller_> joining
[19:38] <hatch> can anyone comment on the best way to get syntax coloring in bzr status/diff  in ubuntu terminal?
[19:45] <benji> hatch: I pipe them to vim so it can colorize them, like so: "bzr diff | vim -"
[19:47] <benji> hatch: I just discovered "colordiff" which is apt-get installable which does what you want ("bzr diff | colordiff")
[19:50] <hatch> ahh cool, doesn't do status but I can live without
[19:52] <benji> hatch: "status"?
[19:52] <hatch> `bzr status` show the changed files
[19:52] <benji> ah, you want git-style colors for added, modified, etc?
[19:52] <hatch> yeah I figure we aren't going to be switching to git so I better get bzr setup the way I like it :)
[19:52] <bac> benji: what version of go are you running?
[19:53] <benji> bac: "go version" says "go version go1.0.2"
[19:54] <bac> benji: yeah, me too.  i had 1.0.3 on 32 bit vm but there is not build for amd64 in the PPA.  so '-u' no longer works
[19:54] <bac> well, it isn't supported
[19:54] <benji> hatch: you might also be interested in bzrtools which includes a "cdiff" command that is a colorized diff
[19:54] <benji> bac: what does "-u" do?
[19:54] <bac> it is supposed to update dependent packages
[19:55] <benji> ah
[19:55] <bac> gets rid of those test warnings
[19:55] <bac> speeds things up
[20:13] <benji> bac: ok, I can write new function (er... method... I wonder what they call these things) that can take aguments and generate responses or errors
[20:14] <bac> benji: cool.  i've 'ported' the get command from the old location to the new and tests pass.  i figured i would put it up for review before wiring in the apiserver parts, similar to the flow roger did
[20:14] <benji> very nice
[20:14] <bac> smaller branch for the first one, fewer things to scrutinize
[20:14] <bac> the tests all pass but i'm having a look now to see if they make sense
[20:15] <hatch> benji: as an alias this gets me pretty close `diff = diff --diff-options -p --using colordiff`
[20:19] <benji> I'm more of a -u kinda guy.
[20:21] <benji> wait, -p doesn't do what I though it does.  I learned something today.
[20:22] <hatch> what does -u do? :)
[20:22] <hatch> I don't see it in the help
[20:24] <benji> -u is "unified" format, which is the default for bzr's diff (but regular old diff has to be told to be sane)
[20:26] <hatch> ahh
[20:31] <hatch> that sputnik 2 laptop is pretty cool but I definitely don't need 256GB ssd and i7 :) I'd be happy to save a few hundred and drop it down to 128 and i5
[20:34] <hatch> ok 16GB ram, 128GB SSD, i5
[20:37] <hatch> 15" screen 8H battery life...4.5lbs
[20:37] <hatch> well ok might as well add back in the 256GB SSD
[20:38] <hatch> and something above 200 ppi
[20:38] <hatch> ;)
[20:38] <hatch> I think I just doubled the price of the computer
[20:43] <benji> yow, not only does go have labled continue, the go-juju code uses it
[21:23] <bac> hatch: yeah, now that they bumped up the resolution on the sputnik display it is more reasonable
[21:24] <hatch> bac: yeah honestly the laptop that I want is the 15" MBP - ignoring the OS it's probably the best hardware option
[21:25]  * bac won't disagree
[21:29]  * bac o/
[21:56] <gary_poster> Makyo, reviewed.  thank you.  Maybe hatch can give you another review. :-)
[21:56]  * gary_poster must run
[21:56] <hatch> I can do that
[21:58] <Makyo> Thanks, gary_poster.  Have a good evening.
[22:04] <hatch> Makyo: pulling it down now
[22:05] <Makyo> hatch, no rush.  I've got some minors from Gary and another task besides.
[22:09] <hatch> if I want to comment on a 'user experience' thing where should I put that?
[22:10] <hatch> comment on [revision details] ?
[22:11] <hatch> ^ jujugui
[22:12] <Makyo> hatch, When you submit your comments on the review, you'll have the chance to prefix the comments with general notes and UX stuff.
[22:12] <bcsaller_> You can also bring it up with nick at tomorrow's meeting and arrange for feedback
[22:13] <Makyo> hatch, What bcsaller_ said, too; all our UX stuff can be made as suggestions to our UX guys; it'll have to go through them during UX check, anyway :)
[22:16] <hatch> gotcha :)
[22:16] <hatch> ok message sent
[22:16] <Makyo> hatch, can you confirm against trunk?
[22:19] <hatch> can do
[22:19] <hatch> checking
[22:20] <hatch> Makyo: works as expected on trunk
[22:20] <hatch> sorry ;)
[22:21] <Makyo> hatch, no worries, just curious, since I didn't really touch that.
[22:22] <hatch> ahh - well I'll hold off on a code review then :) Should I create a bug or is the comment enough?
[22:27] <Makyo> hatch, comment's enough.
[22:29] <Makyo> Can do the code review if you want, will just be appended to the list of things to do.
[22:59] <hatch> ok just finished
[23:13] <Makyo> hatch, Thanks.  I agree about the isValue thing, but it's been standard in the past.  Maybe worth bringing up on a call?
[23:14] <hatch> sure.....let the new guy take the heat!!!
[23:14] <hatch> :P
[23:14]  * Makyo helpful :D
[23:14] <Makyo> Nah, we'll bring it up and see what we think.
[23:14] <hatch> haha - sounds good
[23:19] <hatch> so after using this new ram for the afternoon it appears that I can no longer run two monitors, one through the TB port and one through the HDMI - almost immediatly after plugging in the HDMI one the TB display goes black
[23:19] <hatch> :/
[23:22] <hatch> I wonder if the gpu is sharing memory or something