| gary_poster | Making 1000 units is fun and easy in the in-memory GUI :-) | 00:02 |
|---|---|---|
| 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:03 |
| gary_poster | still ok | 00:04 |
| gary_poster | really big boxes | 00:04 |
| hatch | lol | 00:04 |
| gary_poster | I have a chromium browser process using 825.5 M. Maybe that's it? I'll make 30000... | 00:05 |
| hatch | hahahaha | 00:06 |
| gary_poster | no, it was the one using 400M, 556M now | 00:07 |
| gary_poster | and that's a double database | 00:07 |
| gary_poster | one for in-memory juju, one for the GUI side | 00:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| gary_poster | well, no guarantees for not going bonkers :-) | 00:15 |
| hatch | haha so true | 00:15 |
| hatch | chome devtools remote debugging is so cool | 02:53 |
| rick_h_ | hatch: agreed | 03:02 |
| rick_h_ | I need to set it up actually though still. | 03:02 |
| 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:05 |
| 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:06 |
| * 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:10 |
| 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:11 |
| 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:12 |
| 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 | 03:13 |
| frankban | morning fwereade__, thanks for your review | 08:59 |
| fwereade__ | frankban, heyhey | 08:59 |
| fwereade__ | frankban, helpful I hope? | 08:59 |
| frankban | fwereade__: absolutely | 09:00 |
| 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:01 |
| fwereade__ | frankban, hmm, I'm not sure we do | 09:02 |
| fwereade__ | frankban, we *might* | 09:02 |
| 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:03 |
| fwereade__ | frankban, probably best to make it explicit | 09:04 |
| 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:06 |
| frankban | fwereade__: and maybe a map that maps collection names to entityName prefixes | 09:09 |
| fwereade__ | frankban, I think you only need the second function for now | 09:10 |
| fwereade__ | frankban, but, yeah, it probably deserves to be a top-level (but unexported) function in state | 09:11 |
| frankban | fwereade__: ok. so that function will explicitly use a map[entityname-prefix]coll-name, right? | 09:12 |
| 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 | 09:17 |
| === bcsaller_ is now known as bcsaller | ||
| 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:45 |
| gary_poster | cool | 13:47 |
| bcsaller | gary_poster: in chat when you're ready | 13:47 |
| hatch | good morning | 14:02 |
| rick_h_ | hatch: morning, comments for you in the review. Let me know if anything doesn't make sense. :) | 14:03 |
| hatch | okee | 14:03 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| hatch | yay no more writeonce | 14:12 |
| hatch | rick_h_ I didn't know about the linter causing issues on named methods like that | 14:14 |
| hatch | thats...lame | 14:14 |
| rick_h_ | hatch: yea, I guess I can move the callbacks into methods on the class but seemed...unnecessary | 14:15 |
| 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:16 |
| hatch | I mean, it doesn't apply at all in this situation | 14:17 |
| hatch | :) | 14:17 |
| 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:21 |
| gary_poster | hatch, yes | 14:22 |
| gary_poster | make sense to you, hatch? | 14:22 |
| hatch | yep that makes the most sense if we want to display the date in their local timezone | 14:23 |
| gary_poster | cool | 14:24 |
| Makyo | jujugui call now? | 14:30 |
| hatch | yup | 14:30 |
| === benji___ is now known as benji | ||
| === matsubara_ is now known as matsubara | ||
| teknico | rogpeppe, any idea about these test errors in trunk? http://pastebin.ubuntu.com/5637181/ | 15:05 |
| 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:07 |
| rogpeppe | teknico: looks like it's been broken not that long ago. there's no test image data for quantal 386 | 15:13 |
| rogpeppe | teknico: this should be fixed very soon. | 15:14 |
| teknico | rogpeppe, great, thanks | 15:14 |
| bac | frankban: can you provide a reference in juju-core where your errors.New trick is used and checked? | 15:34 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:48 |
| bac | thanks frankban | 15:59 |
| hatch | gary_poster what date format are we using? ISO 8601? | 16:16 |
| hatch | YYYY-DD-MM | 16:16 |
| hatch | er | 16:17 |
| gary_poster | typically yyyy-mm-dd hatch | 16:17 |
| hatch | YYYY-MM-DD | 16:17 |
| gary_poster | y | 16:17 |
| hatch | anyone looking for a break to do a small review? https://codereview.appspot.com/7722045/ | 16:26 |
| rick_h_ | hatch: looking | 16:28 |
| hatch | thanks | 16:28 |
| hatch | one more?? bueller....bueller? | 16:36 |
| gary_poster | looking hatch | 16:42 |
| hatch | why thank you | 16:45 |
| === deryck is now known as deryck[lunch] | ||
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| hatch | oh great | 16:55 |
| teknico | benji, thank you :-) | 16:58 |
| gary_poster | hatch LGTM with changes | 16:58 |
| * gary_poster goes to eat something before calls | 16:59 | |
| hatch | thanks | 16:59 |
| hatch | bcsaller: do you have some time today to give me a runthrough of how the d3 and yui events are set up? | 17:29 |
| 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:30 |
| === matsubara is now known as matsubara-lunch | ||
| bcsaller | hatch: sounds like you have a call with gary now | 17:41 |
| hatch | yup sorry :) | 17:42 |
| Makyo | I'm at 1.5kloc diff and only a third done. This branch is getting out of hand. | 18:06 |
| hatch | lol | 18:06 |
| === deryck[lunch] is now known as deryck | ||
| hatch | bcsaller: ok all done, meet in guichat? | 18:07 |
| bcsaller | hatch: heading there now | 18:08 |
| rogpeppe | bac: ping | 18:18 |
| bac | hi rogpeppe | 18:19 |
| rogpeppe | bac: just looking at the GetEndpoints proposal | 18:19 |
| bac | me too | 18:19 |
| === matsubara-lunch is now known as matsubara | ||
| rogpeppe | bac: i'm just wondering why it's not just ServiceCharmInfo | 18:19 |
| 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:20 |
| 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:22 |
| rogpeppe | bac: i'm concerned that there's considerable overlapping of functionality here without much gain that i can see | 18:23 |
| hazmat | this is the get_service method? | 18:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| rogpeppe | hazmat: yup | 18:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| frankban | have a great weekend all | 18:58 |
| hatch | Makyo: you mentioned yesterday that you implemented the two finger touch - mind pointing me to where that's done? | 19:01 |
| hatch | I'm slowly making progress on this :) | 19:02 |
| Makyo | hatch, D3 implements that. Just a sec. | 19:02 |
| hatch | oh alright | 19:03 |
| Makyo | https://github.com/mbostock/d3/blob/master/src/behavior/drag.js | 19:03 |
| hatch | thanks | 19:07 |
| hatch | OOOoo | 19:13 |
| * hatch takes one step closer to a solution | 19:13 | |
| hatch | ok I found the problem | 19:21 |
| hatch | unfortunately a sollution won't be ideal | 19:21 |
| 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:27 |
| hatch | firefox is doing it properly ;) | 19:28 |
| hatch | THIS time | 19:28 |
| hatch | lol | 19:28 |
| benji | I was speaking apropos of my recent experiences. | 19:29 |
| 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:30 |
| 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:58 |
| bcsaller | hatch: chat? | 19:59 |
| hatch | sure | 19:59 |
| * bac -> early dog walk. bbiab. | 20:03 | |
| hatch | ok going to take lunch | 20:23 |
| hatch | bak | 21:11 |
| hatch | sooo anyone have any big plans for the weekend? | 21:20 |
| gary_poster | stop being sick, & actually sleep through the night | 21:28 |
| hatch | pfft a full nights sleep is WAY overrated | 21:29 |
| hatch | so close to getting this to work | 21:43 |
| hatch | MOHOHOHAHAHAHAHA | 21:49 |
| * hatch yells at chome android "AND STAY DOWN!" | 21:50 | |
| hatch | bcsaller: you kickin around still? | 21:56 |
| hatch | jcsackett: is this branch ready for review? | 22:17 |
| rick_h_droid | hatch how does 0.0.0.0 fail on your machine? | 23:07 |
| 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:08 |
| 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:09 |
| hatch | lemme see | 23:10 |
| hatch | nope | 23:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| hatch | so if that gets changed to a real ip then it breaks | 23:15 |
| rick_h_droid | hmm so normally changing local host can cause issues. surprised you've got it changed up. | 23:16 |
| 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:17 |
| rick_h_droid | very handy trick to know | 23:18 |
| 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:20 |
| 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:21 |
| hatch | being able to create your own server at whatever port you want is a huge plus | 23:22 |
| 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:24 |
| hatch | so 0.0.0.0 should be pointing to 127.0.0.1 | 23:25 |
| hatch | yeah I definitely broke something somewhere | 23:27 |
| hatch | well you know what that means....time for a new computer....obviously! | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
