[00:02] <gary_poster> Making 1000 units is fun and easy in the in-memory GUI :-)
[00:03] <gary_poster> Now I have 5000!
[00:03] <gary_poster> It's big
[00:03] <hatch> haha
[00:03]  * hatch waits for it to crash
[00:03] <gary_poster> :-) I was wondering about that.
[00:03] <gary_poster> I'll try 10000
[00:04] <gary_poster> still ok
[00:04] <gary_poster> really big boxes
[00:04] <hatch> lol
[00:05] <gary_poster> I have a chromium browser process using 825.5 M.  Maybe that's it?  I'll make 30000...
[00:06] <hatch> hahahaha
[00:07] <gary_poster> no, it was the one using 400M, 556M now
[00:07] <gary_poster> and that's a double database
[00:08] <gary_poster> one for in-memory juju, one for the GUI side
[00:10] <hatch> that's pretty good
[00:10] <gary_poster> 46000 units total
[00:10] <hatch> lol - I would be worried that the ws would be very bogged down trying to communicate that many changes
[00:11] <gary_poster> yeah
[00:11] <gary_poster> that's the bigger concern I think
[00:11] <hatch> well and the svg rendering
[00:11] <gary_poster> nah
[00:12] <gary_poster> we're talking units not services
[00:12] <gary_poster> I only have four services
[00:12] <hatch> ohh ok
[00:12] <gary_poster> the biggest use case we've heard of is about 14 services
[00:12] <gary_poster> and we expect to nolonger support > 30
[00:12] <gary_poster> s/nolonger/not/
[00:13] <hatch> woah ...did you just edit that line?
[00:13] <gary_poster> hatch how can I get your LGTM.  You want me to push, even with the merge, and point out what I changed?
[00:13]  * hatch just entered the danger zone I think
[00:13] <hatch> oh no I'll just add it
[00:13] <gary_poster> hatch, that's your irc client.  It probably honors the vi style substitutions
[00:14] <gary_poster> I said s/nolonger/not/
[00:14] <gary_poster> and it did what I asked :-)
[00:14] <hatch> hahaha wow
[00:14] <gary_poster> but over the wire it is still as I sent it
[00:14] <hatch> I thought I was going bonkers
[00:14] <gary_poster> originally
[00:15] <gary_poster> well, no guarantees for not going bonkers :-)
[00:15] <hatch> haha so true
[02:53] <hatch> chome devtools remote debugging is so cool
[03:02] <rick_h_> hatch: agreed
[03:02] <rick_h_> I need to set it up actually though still. 
[03:05] <hatch> I messed around trying to solve these android bugs for a while this afternoon - found what caused it to fail in about 1min after setting that up
[03:05] <hatch> haha
[03:05] <hatch> no idea how to fix it yet
[03:05] <hatch> but found the root cause :)
[03:05] <rick_h_> lol, well knowing wtf is broken is half the battle :)
[03:06] <rick_h_> I'm too tired to think straight but we should look at https://bugs.launchpad.net/juju-gui/+bug/1158613 first thing in the morning
[03:06] <_mup_> Bug #1158613: timestamp handling is not TZ aware <juju-gui:Triaged> < https://launchpad.net/bugs/1158613 >
[03:06] <rick_h_> poor huw in australia can't land a branch due to a bad test around timezone conversion lol
[03:06] <hatch> ugh I spent months working on timezone aware date stuff and swore i'd never do it again
[03:06] <hatch> apparently I didn't swear loud enough
[03:06] <hatch> lol
[03:06] <rick_h_> lol, then you never saw this ... 
[03:10]  * hatch has been waiting impatiently for the reveil
[03:10] <hatch> reveal even
[03:10] <rick_h_> reveal?
[03:10] <hatch> I was waiting for you to link to something
[03:11] <hatch> :)
[03:11] <rick_h_> the bug above?
[03:11] <hatch> no some library that solved timezone issues in javascript
[03:11] <rick_h_> oh no, just the bug comes about due to his browser/timezone saying the date is the 10th, but the test thinks it should be the 9th
[03:11] <rick_h_> so he can never pass the tests
[03:11] <rick_h_> and thus lbox denies him
[03:12] <hatch> oh right - because the test doesn't specify timezone
[03:12] <rick_h_> right
[03:12] <rick_h_> so when it's not past bedtime I'll look I guess at what the code does vs the test does and see what needs to get updated
[03:13] <rick_h_> just find it funny the poor guy can't land a branch because of his TZ
[03:13] <rick_h_> or put it up for code review even
[03:13] <hatch> lol see timezones-the-devil
[03:13] <hatch> http://i10.photobucket.com/albums/a121/Elvislover01/Elvislover03/TheWaterboy.jpg
[08:59] <frankban> morning fwereade__, thanks for your review
[08:59] <fwereade__> frankban, heyhey
[08:59] <fwereade__> frankban, helpful I hope?
[09:00] <frankban> fwereade__: absolutely
[09:01] <frankban> fwereade__: re "you'll need to be able to map from entity name back to collection/_id", can I assume coll/_id == entityName.split('-') and then coll += 's'?
[09:01] <frankban> fwereade__: do we have that kind of convention?
[09:02] <fwereade__> frankban, hmm, I'm not sure we do
[09:02] <fwereade__> frankban, we *might*
[09:03] <fwereade__> frankban, but it is not something I have thought about consciously
[09:03] <frankban> fwereade__: it seems fragile, except if there is a strong convention in that sense
[09:03] <fwereade__> frankban, indeed
[09:04] <fwereade__> frankban, probably best to make it explicit
[09:06] <frankban> fwereade__: are you thinking about two functions, probably living in state, e.g. makeEntityName(id, coll string) string and parseEntityName(name string) (string string error)?
[09:09] <frankban> fwereade__: and maybe a map that maps collection names to entityName prefixes
[09:10] <fwereade__> frankban, I think you only need the second function for now
[09:11] <fwereade__> frankban, but, yeah, it probably deserves to be a top-level (but unexported) function in state
[09:12] <frankban> fwereade__: ok. so that function will explicitly use a map[entityname-prefix]coll-name, right?
[09:17] <fwereade__> frankban, implement it as it pleases you to do, I just care that it's in one place and explicit of purpose
[09:17] <frankban> fwereade__: cool, thanks
[13:45] <gary_poster> bcsaller, I'm ready to talk any time.  I have my vpn up and am staring mutely at the most recent failure
[13:45] <gary_poster> but no rush at all :-)
[13:45] <bcsaller> gary_poster: thats a good place to start :) I can join the chat in a second
[13:47] <gary_poster> cool
[13:47] <bcsaller> gary_poster: in chat when you're ready
[14:02] <hatch> good morning
[14:03] <rick_h_> hatch: morning, comments for you in the review. Let me know if anything doesn't make sense. :)
[14:03] <hatch> okee
[14:06] <hatch> rick_h_ thanks - what I meant about that check in the setter was if somehow it gets passed in "@#$%" it will still pass your check and then output NaN
[14:06] <hatch> so the only thing it pretects from is empty strings
[14:06] <hatch> protects
[14:06] <hatch> and undefined I guess
[14:07] <rick_h_> hatch: ah gotcha. I mean these are coming from a known source. I don't know it's worth going crazy on it. I guess I can run through Y.Lang.isString || Number ?
[14:08] <hatch> well I would just dump the check all together - like you said, it's coming from a known source, and if it's ok if it has NaN/undefined as a value then it really doesn't matter
[14:08] <rick_h_> hatch: cool
[14:10] <hatch> hehe Url vs URL - that one has also always bugged me, I can't decide which one I like better - jcsackett
[14:10] <hatch> :)
[14:10] <rick_h_> I prefer lower because it starts to look too constant-y for my tastes, but it's a preference thing. Don't want to get hung up on it
[14:11] <jcsackett> rick_h_: yeah, it's not a big deal. my english major side jumped out and said "that's an acronym!". feel free to ignore the english major side. :-P
[14:12] <hatch> yay no more writeonce
[14:14] <hatch> rick_h_ I didn't know about the linter causing issues on named methods like that
[14:14] <hatch> thats...lame
[14:15] <rick_h_> hatch: yea, I guess I can move the callbacks into methods on the class but seemed...unnecessary
[14:16] <hatch> yeah I'm going to say that I THINK the preferred way is to specify a string for the fn name in the class to promote lazy loading the attributes
[14:16] <hatch> but I'm not sure the specifics on that right now
[14:17] <hatch> I mean, it doesn't apply at all in this situation
[14:17] <hatch> :)
[14:21] <hatch> gary_poster: wrt https://bugs.launchpad.net/juju-gui/+bug/1158613 would you prefer we build the string that it's supposed to look like in the test?
[14:21] <_mup_> Bug #1158613: timestamp handling is not TZ aware <juju-gui:Triaged by hatch> < https://launchpad.net/bugs/1158613 >
[14:22] <gary_poster> hatch, yes
[14:22] <gary_poster> make sense to you, hatch?
[14:23] <hatch> yep that makes the most sense if we want to display the date in their local timezone
[14:24] <gary_poster> cool
[14:30] <Makyo> jujugui call now?
[14:30] <hatch> yup
[15:05] <teknico> rogpeppe, any idea about these test errors in trunk? http://pastebin.ubuntu.com/5637181/
[15:07] <rogpeppe> teknico: something to do with the recent stuff around version.Current, i think. you're running quantal, presumably?
[15:07] <teknico> rogpeppe, yep
[15:13] <rogpeppe> teknico: looks like it's been broken not that long ago. there's no test image data for quantal 386
[15:14] <rogpeppe> teknico: this should be fixed very soon.
[15:14] <teknico> rogpeppe, great, thanks
[15:34] <bac> frankban: can you provide a reference in juju-core where your errors.New trick is used and checked?
[15:40] <frankban> bac: my code changed so I didn't use that technique directly. however a quick search for errors.New gave me this example: ErrSilent in cmd/cmd.go
[15:41] <hatch> gary_poster: you asked me to teach you how to do remote debugging - https://developers.google.com/chrome-developer-tools/docs/remote-debugging this does a better job than I caould :D
[15:42] <hatch> could* damn I can't talk today
[15:42] <gary_poster> hatch, ok awesome thanks :-)
[15:42] <hatch> if you run into issues then maybe I can help debug but as far as a step by step guide goes it's pretty awesome
[15:48] <bac> frankban: sorry, but my internet dropped out after i sent you that request.  if you posted something could you post it again?
[15:48] <frankban> bac: my code changed so I didn't use that technique directly. however a quick search for errors.New gave me this example: ErrSilent in cmd/cmd.go
[15:59] <bac> thanks frankban
[16:16] <hatch> gary_poster what date format are we using? ISO 8601?
[16:16] <hatch> YYYY-DD-MM
[16:17] <hatch> er
[16:17] <gary_poster> typically yyyy-mm-dd hatch
[16:17] <hatch> YYYY-MM-DD
[16:17] <gary_poster> y
[16:26] <hatch> anyone looking for a break to do a small review? https://codereview.appspot.com/7722045/
[16:28] <rick_h_> hatch: looking
[16:28] <hatch> thanks
[16:36] <hatch> one more?? bueller....bueller?
[16:42] <gary_poster> looking hatch
[16:45] <hatch> why thank you
[16:49] <hazmat> wrt to the jenkins tests we should ideally execute juju with verbose options and stdout/stderr captured so we have  a bit more context than cmd failed
[16:49] <hatch> oh believe me
[16:49] <hatch> we've tried
[16:49] <hatch> ;)
[16:50] <hatch> jenkins is all like 'debug output? - NO!'
[16:50] <hazmat> jenkins isn't the issue ..
[16:50] <hazmat> its the way shelltoolbox is being used along with the cli args to juju
[16:51] <hazmat> jenkins is clearly capturing the traceback from shelltoolbox.. but the underlying output isn't being sent back
[16:51] <hatch> ohh
[16:51] <benji> hatch: here is a diff that will remove the irritating message from the end of the gjslint output: http://paste.ubuntu.com/5637488/
[16:52] <hatch> benji: awesome :)
[16:52] <benji> (it also makes the file name line number messages nicer, I (and others I assume) have tools that interpret file locations like those)
[16:52] <benji> it's a bit of a hack, but it should be good enough
[16:52] <hazmat> added a card for capturing useful output on testing
[16:55] <hatch> oh great
[16:58] <teknico> benji, thank you :-)
[16:58] <gary_poster> hatch LGTM with changes
[16:59]  * gary_poster goes to eat something before calls
[16:59] <hatch> thanks
[17:29] <hatch> bcsaller: do you have some time today to give me a runthrough of how the d3 and yui events are set up?
[17:30] <bcsaller> hatch: yeah, wanna say in 10 minutes in chat?
[17:30] <hatch> sounds good to me
[17:30] <hatch> I can't even get the popup to display by simulating the click right on the service because it's being prevented somewhere so a guide would REALLy help :D
[17:41] <bcsaller> hatch: sounds like you have a call with gary now
[17:42] <hatch> yup sorry :)
[18:06] <Makyo> I'm at 1.5kloc diff and only a third done.  This branch is getting out of hand.
[18:06] <hatch> lol
[18:07] <hatch> bcsaller: ok all done, meet in guichat?
[18:08] <bcsaller> hatch: heading there now
[18:18] <rogpeppe> bac: ping
[18:19] <bac> hi rogpeppe
[18:19] <rogpeppe> bac: just looking at the GetEndpoints proposal
[18:19] <bac> me too
[18:19] <rogpeppe> bac: i'm just wondering why it's not just ServiceCharmInfo
[18:20] <rogpeppe> bac: returning the same thing that CharmInfo does for each service
[18:20]  * bac looks at CharmInfo
[18:20] <rogpeppe> bac: essentially it looks like you're reconstructing almost all of the information within the charm metadata
[18:22] <bac> rogpeppe: it is a subset and we want the ability to get for all services at once, rather than having to make multiple calls
[18:22] <rogpeppe> bac: in fact... i'm wondering if something that simply returned the charm url for each requested service might be better.
[18:22] <rogpeppe> bac: then you can call CharmInfo for each unique url found
[18:22] <bac> rogpeppe: also, i read my task to be to implement the same functionality hazmat had made available in pyjuju
[18:23] <rogpeppe> bac: i'm concerned that there's considerable overlapping of functionality here without much gain that i can see
[18:24] <hazmat> this is the get_service method?
[18:25] <bac> hazmat: get_endpoints
[18:25] <rogpeppe> bac: if we had a ServiceInfo call that returned a []struct{Name string; CharmURL string; other possible service info}, then i think that would be useful and then CharmInfo remains the definitive place to find endpoint info
[18:27] <rogpeppe> hazmat: perhaps you have a different perspective on why get_endpoints is useful though?
[18:27] <benji> gary_poster: is my branch going to have massive conflicts with your in-memory environment branch?
[18:28] <hazmat> rogpeppe, it was an optimization, to prevent the gui having to fetch every charm's info separately, instead just getting interface prov/requires by svc
[18:28] <hazmat> in a single call
[18:28] <hazmat> otherwise you end up with the gui having to do N + N round trips (get service info, get charm info)
[18:28] <rogpeppe> hazmat: if we have many services sharing the same charm, it might be a false optimisation :-)
[18:29] <rogpeppe> hazmat: i don't think so. if we allowed ServiceInfo to return many services, then i think only 2 round trips are required.
[18:29] <gary_poster> benji don't know but mine landed
[18:29] <hazmat> rogpeppe, that's not that common in general re many svcs using the same charm. possible though
[18:29] <rogpeppe> hazmat: there's no problem with launching N API calls concurrently
[18:30] <benji> gary_poster: oh, cool; in that case I've already merged it and didn't feel much pain  :)
[18:30] <gary_poster> great
[18:30] <rogpeppe> hazmat: although i suppose the js client interface might not have allowed for that possibility
[18:30] <hazmat> rogpeppe, its not a question of feasibility but of latency till the info can be processed.
[18:30] <hazmat> rogpeppe, it does
[18:30] <hazmat> all commands are async to the gui
[18:31] <hazmat> but i don't think there is a notion of launch N and wait till N has completed .. ie group deferred/promise
[18:31] <rogpeppe> hazmat: it wouldn't be hard to do
[18:31] <rogpeppe> hazmat: i'm not sure that two round trips is too bad, is it?
[18:32] <hazmat> rogpeppe, you'll have to be a bit more explicit
[18:32] <hazmat> rogpeppe, you saying a ServiceInfos method returning list of service infos and a CharmInfos method returning list of charm infos for a given set of charm urls?
[18:33] <rogpeppe> hazmat: yes to the former, no to the latter
[18:33] <hazmat> this info feeds into a gui endpoint solver which determines what the valid relations are for the env to allow for drag/drop relations with appropriate ui (disable invalid targest, etc)
[18:34] <rogpeppe> hazmat: the former because it's good to be able to ask for all services. the latter because we don't want to enumerate all charms, and sending N CharmInfo calls at once should not be a problem.
[18:35] <hazmat> rogpeppe, why the distinction?
[18:35] <hazmat> ie what's wrong with CharmInfos([list-of-charm-urls])
[18:35] <rogpeppe> hazmat: why bother?
[18:35] <hazmat> but thats okay with ServiceInfos  returning a list?
[18:36] <rogpeppe> hazmat: we need some way of finding out all the current services
[18:36] <rogpeppe> hazmat: but i don't think we need a way to find out all charms in the State.
[18:36] <hazmat> rogpeppe, it was parameterized.. not all in the state.. all in use by current services
[18:37] <hazmat> but paramterized so the gui can just fetch those it doesn't hvae info for
[18:37] <hazmat> the notion also grows more murky as you consider things like upgrades
[18:37] <hazmat> you need the service watch to inform on charm changes
[18:37] <rogpeppe> hazmat: yes, it will (and actually does currently)
[18:37] <hazmat> cool
[18:38] <rogpeppe> hazmat: that's why i see CharmInfo as more important than GetEndpoints
[18:38] <rogpeppe> hazmat: it seems right that the GUI (as well as the state) keeps a notion of what charms it currently has information about
[18:38] <rogpeppe> hazmat: and invokes CharmInfo for any it doesn't
[18:39] <hazmat> that's seems okay.. bac the client side implementation can basically keep the same interface and internally fetch for what it doesn't have, invoking callback when complete.
[18:40] <rogpeppe> hazmat: in fact, that's another reason why GetEndpoints isn't that useful - the AllWatcher will tell us about all current services
[18:40] <hazmat> that's not its purpose..
[18:41] <rogpeppe> hazmat: isn't that how the GUI finds out about everything to start with?
[18:41] <hazmat> its purpose is to determine the endpoints when the allwatcher fires and the service set changes
[18:41] <hazmat> rogpeppe, yes the gui uses the delta stream to populate. i was referencing the method being discussed.. get_endpoints
[18:42] <bac> rogpeppe, hazmat: so, in juju-core GetEndpoints is thrown away.  do we then need new APIs to provide the required information or do those exist already?
[18:42] <rogpeppe> hazmat: yes, so the service set changes - we see the new charm urls and fetch information for them, which gives us the endpoints associated with the services, no?
[18:42] <rogpeppe> bac: i *think* you already have all you need
[18:42] <hazmat> rogpeppe, yes, that's fine the gui client side go implementation can implement this ontop of the primitives
[18:42] <hazmat> namely CharmInfo(charm_url)
[18:43] <rogpeppe> hazmat: yup
[18:44] <hazmat> bac, so effectively on get_endpoints in the go env impl client side.. you'll call CharmInfo(charm_url) for any services known that don't have charm info fetched, and then flatten that metadata back into provides:[interfaces], requires:[interfaces]
[18:44] <hazmat> and then invoke the callback for the result, that should satisfy the interface for the valid endpoint solver.
[18:44] <rogpeppe> bac: sorry to push back on this (and your implementation was fine!) but i do think that GetEndpoints isn't necessary, and i'd like to keep overall the surface area small if possible.
[18:45] <bac> hazmat: what is the equivalent of get_endpoints() [no services specified]?  where will i get the list of services we're interested in?
[18:45] <hazmat> bac, if none are spec'd its whatever are known to the gui
[18:45] <bac> rogpeppe: makes sense.  wish we'd talked before the work was done
[18:46] <bac> hazmat: yeah, ok
[18:46] <hazmat> bac, ic the env impl doesn't have a client db handle to determine that? is that the concern?
[18:46] <bac> hazmat: don't know yet.  not that familiar with it and will have to look
[18:47] <rogpeppe> bac: yes, sorry. perhaps we should have a meeting about upcoming proposed API additions, so we can find issues like this earlier
[18:47] <hazmat> bac you can walk up the parent tree of event targets... although explicit component lookup would be nicer.
[18:48] <rogpeppe> bac: i'm really sorry; i know how frustrating it is!
[18:48] <gary_poster> bac, I guess this is where you write the JS version and then we steal it for the in-browser-memory Python version too.  
[18:48]  * rogpeppe has got to weekend time
[18:48] <rogpeppe> g'night all
[18:48] <bac> bye rogpeppe
[18:58] <frankban> have a great weekend all
[19:01] <hatch> Makyo: you mentioned yesterday that you implemented the two finger touch - mind pointing me to where that's done?
[19:02] <hatch> I'm slowly making progress on this :)
[19:02] <Makyo> hatch, D3 implements that.  Just a sec.
[19:03] <hatch> oh alright
[19:03] <Makyo> https://github.com/mbostock/d3/blob/master/src/behavior/drag.js 
[19:07] <hatch> thanks
[19:13] <hatch> OOOoo
[19:13]  * hatch takes one step closer to a solution
[19:21] <hatch> ok I found the problem
[19:21] <hatch> unfortunately a sollution won't be ideal
[19:27] <hatch> ok it looks like chrome android doesn't convert the touchstart to a click like firefox does - AND touchstart doesn't bubble on svg elements either
[19:27] <hatch> so it's kind of like a double edged sword
[19:27] <benji> I swear, firefox is a piece of crap
[19:28] <hatch> firefox is doing it properly ;)
[19:28] <hatch> THIS time
[19:28] <hatch> lol
[19:29] <benji> I was speaking apropos of my recent experiences.
[19:30] <hatch> ahh - time for "works best in ..." images again
[19:30] <hatch> haha
[19:30] <hatch> Boo Yeah!
[19:30] <hatch> got er fixed...it's ugly as sin though so I'll have to figure a better way haha
[19:58] <hatch> bcsaller: is there a way I can go from the svg .service element and get the object instance associated with it?
[19:58] <hatch> essentially I need to manually build the 'box' param in serviceClick
[19:59] <bcsaller> hatch: chat?
[19:59] <hatch> sure
[20:03]  * bac -> early dog walk.  bbiab.
[20:23] <hatch> ok going to take lunch
[21:11] <hatch> bak
[21:20] <hatch> sooo anyone have any big plans for the weekend?
[21:28] <gary_poster> stop being sick, & actually sleep through the night
[21:29] <hatch> pfft a full nights sleep is WAY overrated
[21:43] <hatch> so close to getting this to work
[21:49] <hatch> MOHOHOHAHAHAHAHA
[21:50]  * hatch yells at chome android "AND STAY DOWN!"
[21:56] <hatch> bcsaller: you kickin around still?
[22:17] <hatch> jcsackett: is this branch ready for review?
[23:07] <rick_h_droid> hatch how does 0.0.0.0 fail on your machine? 
[23:08] <hatch> localhost points to the 'localhost' that I need not to 0.0.0.0
[23:08] <rick_h_droid> right so local host reeves to 127.0.0.1 right? 
[23:09] <hatch> nope, totally different internal ip
[23:09] <rick_h_droid> and 0.0.0.0 will bind to all network addresses and work on 127.0.0.1 
[23:09] <rick_h_droid> hmm and 0.0.0.0 doesn't bind to this address? 
[23:10] <hatch> lemme see
[23:11] <hatch> nope
[23:12] <hatch> actually I'm not even sure what it's binding to
[23:12] <hatch> I should look into that
[23:12] <rick_h_droid> ugh what have you got set up :p
[23:12] <hatch> I used to be a contractor - who knows what kind of setup I have screwed up here lol
[23:13] <rick_h_droid> generally you use the 0s trick to bond both local and external addresses so you can test from remote machines like IE in  vm oe windows machine. 
[23:14] <rick_h_droid> so jcsackett 's change was probably done to run tests from another machine. but it shouldn't break local host. 
[23:14] <hatch> ahh I gotcha - yeah see I have localhost pointing to a specific local ip
[23:15] <hatch> so if that gets changed to a real ip then it breaks
[23:16] <rick_h_droid> hmm so normally changing local host can cause issues. surprised you've got it changed up. 
[23:17] <rick_h_droid> but yea. it's intentional but usually not an issue so not done with any intent to change how things work. 
[23:17] <hatch> yeah I figured it was committed by accident that's why I commented
[23:17] <hatch> well and that it'll break the first time i use it haha
[23:17] <hatch> but i should look into what's going on with 0.0.0.0
[23:18] <rick_h_droid> very handy trick to  know 
[23:20] <hatch> I was once working on three different apache/php based projects at once
[23:20] <hatch> just imagine the headache setting THAT up
[23:20] <hatch> ugh
[23:21] <rick_h_droid> heh used to do php so I understand
[23:21] <hatch> the best part about not doing php - is not having to deal with apache for that stuff
[23:22] <hatch> being able to create your own server at whatever port you want is a huge plus
[23:24] <hatch> so just so I get this right, you're saying that 0.0.0.0 should be pointing to any of the ip's that the machine thinks it has
[23:25] <hatch> so 0.0.0.0 should be pointing to 127.0.0.1
[23:27] <hatch> yeah I definitely broke something somewhere
[23:27] <hatch> well you know what that means....time for a new computer....obviously!