[00:30] <andrewsmedina> its done
[00:30] <andrewsmedina> niemeyer, hazmat https://codereview.appspot.com/5702055
[00:35] <niemeyer> andrewsmedina: Woohay!
[00:35] <andrewsmedina> niemeyer: :)
[00:36] <niemeyer> andrewsmedina: You should have a review by the morning tomorrow
[00:36] <andrewsmedina> niemeyer: ok :D
[00:37] <andrewsmedina> niemeyer: I will continue to work on local provider (lxc)
[00:47] <hazmat> andrewsmedina, nice
[00:48] <hazmat> i thought that gofmt removed formatting concerns
[00:48] <hazmat> besides subordinates i see alot of formatting/spacing diffs in there
[01:07] <andrewsmedina> hazmat: how I update a issue with other patch using lbox ?
[01:08] <hazmat> andrewsmedina, just lbox propose -cr  again.. it will update in place
[01:09] <andrewsmedina> hazmat: ok, I will fix the format
[01:18] <niemeyer> andrewsmedina: Just run "go fmt"
[01:18] <niemeyer> andrewsmedina: It will auto-format for you
[01:20] <andrewsmedina> niemeyer: I know :p
[01:25] <andrewsmedina> hazmat, niemeyer done :D https://codereview.appspot.com/5702055/
[01:26] <hazmat> andrewsmedina, thanks much nicer
[01:31] <niemeyer> andrewsmedina: How long have you been coding with Go?
[01:34] <andrewsmedina> niemeyer: since carnaval
[01:34] <andrewsmedina> niemeyer: why?
[01:35] <niemeyer> andrewsmedina: Just happy to see how fast you've produced a nice change set for integration
[01:35] <andrewsmedina> niemeyer: I contribute with several projects
[01:36] <niemeyer> andrewsmedina: From a quick look over it, looks very reasonable
[01:36] <andrewsmedina> niemeyer: Most projects that use python
[01:37] <andrewsmedina> niemeyer: I want do more for this project
[01:38] <niemeyer> andrewsmedina: From what I can see so far, you're very welcome to stay
[01:38] <niemeyer> andrewsmedina: make sure you're subscribed to the mailing list too, so that you can also participate in design decisions etc
[01:52] <niemeyer> Woohay.. just cut down the store tests timing by half.. was overlooking a silly setup/teardown cycle
[01:57] <andrewsmedina> niemeyer: If you have more small issues to let me know
[01:57] <niemeyer> andrewsmedina: Thanks, they'll certainly show up, and I'll make sure to ping you to see if you're interested
[01:59] <andrewsmedina> niemeyer: I'm waiting for you :D
[01:59] <andrewsmedina> niemeyer: Now, I will try install c client for zookeper on mac os ou centos
[01:59] <andrewsmedina> =/
[02:01] <niemeyer> andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of gozk from source
[02:01] <niemeyer> Sorry
[02:01] <niemeyer> andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of *zookeeper* from source
[02:01] <niemeyer> andrewsmedina: It's not too painful..
[02:01] <andrewsmedina> niemeyer: I'm not found the c client .tar.gz
[02:02] <niemeyer> andrewsmedina: It's the same source
[02:02] <niemeyer> andrewsmedina: The C client lives under src/c
[02:02] <niemeyer> andrewsmedina: ./configure && make
[02:03] <andrewsmedina> niemeyer: I know, I found this in svn repo, but not in tar.gz package
[02:03] <andrewsmedina> I will try again
[02:04] <andrewsmedina> niemeyer: you were right
[02:05] <niemeyer> andrewsmedina: You'll have to tweak the source of gozk so that the CFLAGS line in zk.go has something like -I/path/to/your/src/c/include
[02:06] <niemeyer> andrewsmedina: We should have a default entry like that pointing to /usr/local/include so that you could just make install it
[02:06] <niemeyer> andrewsmedina: Not there yet, though
[02:08] <andrewsmedina> niemeyer: your project lpad, it's broken with the last weekly version
[02:08] <andrewsmedina> niemeyer: because contains two packages
[02:08] <niemeyer> andrewsmedina: I've already fixed it, but it's lacking the tag I suppose
[02:08] <niemeyer> andrewsmedina: Let me tag it
[02:09] <niemeyer> andrewsmedina: Please try again
[02:09] <andrewsmedina> I have fixed this in my machine :p
[02:09] <andrewsmedina> removing the example.go
[02:13] <niemeyer> andrewsmedina: That works too :)
[02:14] <andrewsmedina> niemeyer: Can I change zk.go to point to /usr/local/include ?
[02:14] <niemeyer> andrewsmedina: Yeah, we can certainly add that in the stock package
[02:14] <niemeyer> andrewsmedina: Just add it at the end, please
[02:20] <niemeyer> Okay.. I really ought to have some sleep now
[02:21] <niemeyer> Have a good night all
[02:21] <niemeyer> Or at least those that approach their bed time ;
[02:21] <niemeyer> )
[11:29] <fwereade> niemeyer, hazmat: will you be free for a chat about constraints in ~90 minutes? (I need to collect Laura and eat lunch pretty soon)
[11:30] <niemeyer> fwereade: I will, but I believe hazmat must be asleep by now
[11:30] <niemeyer> fwereade: Morning, btw
[11:30] <fwereade> niemeyer, heyhey :)
[11:30] <fwereade> niemeyer, ah, ok, he was up late? I often seem to see him come on at about this time
[11:31] <niemeyer> fwereade: Ah, maybe he's changed his working hours
[11:31] <niemeyer> fwereade: I was assuming that just based on his TZ
[11:32] <fwereade> niemeyer, I couldn't swear that's been normal recently, though, it's more a general impression that I developed at some stage
[11:45] <rog> fwereade: so... i did a test implementation of the relation-get thing the way i suggested, and it seemed over complex
[11:45] <fwereade> rog, yeah, I peered through the docs a little and wasn't sure it'd save me much
[11:45] <rog> fwereade: but...
[11:45] <rog> fwereade: i thought this was better: http://paste.ubuntu.com/861798/
[11:45] <rog> fwereade: i think the streaming stuff is overkill
[11:46] <rog> fwereade: for the primitives we're implementing, i don't think there's any need to see output as it's produced.
[11:47] <rog> fwereade: the client side would look like this: http://paste.ubuntu.com/861802/
[11:48] <fwereade_> rog, I'll think about that, but I have to run to collect laura -- sorry
[11:49] <rog> fwereade_: np
[12:50] <rog> lunch
[13:30] <andrewsmedina> morning
[13:50] <andrewsmedina> niemeyer: https://codereview.appspot.com/5702055/
[14:24] <rog> fwereade_: any thoughts about that suggestion?
[14:25] <fwereade_> rog, well, it'd surely work, but it still feels more correct to stream the output back, and I don't really think the setup is that onerous
[14:27] <rog> fwereade_: won't this always be used in a scripting situation where it won't make any difference?
[14:28] <rog> fwereade_: apart from anything else it means that we can rely on a well tested RPC framework rather than rolling our own
[14:29] <fwereade_> rog, well, it seems that it won;t make any difference only if we guarantee that output never grows too irritatingly large to prefer streaming over copying
[14:29] <fwereade_> rog, I think the protocol is independent of the streaming question
[14:30] <fwereade_> rog, we can still stream stuff back with rpc
[14:30] <rog> fwereade_: yeah, but it's a fair amount of complexity. i'm questioning whether that complexity is worth it for some log messages.
[14:30] <rog> fwereade_: the streaming is what makes things more complex, AFAICS
[14:31] <fwereade_> rog, well,and the important output too
[14:31] <rog> fwereade_: but the output is relatively small, right?
[14:31] <rog> fwereade_: no more than 1MB, say
[14:31] <fwereade_> rog, indeed, probably not
[14:31] <rog> fwereade_: (do people put enormous things in relations?)
[14:32] <fwereade_> rog, and, indeed, the stderr output will probably not be ruinously big either
[14:32] <rog> fwereade_: i guess i'm just suggesting an "as simple as possible" approach. the client API looked identical for the streaming RPC version i did
[14:32] <fwereade_> rog, mainly it just feels like packing complete output streams into strings is the Wrong Thing To Do
[14:33] <fwereade_> rog, and I strongly favour implementing all our commands as Commands
[14:34] <rog> fwereade_: it's trivial to make it so there's a single entry that invokes the correct command if that's what we want
[14:34] <rog> fwereade_: (actually i had that before, but thought it might be better with several entry points)
[14:35] <fwereade_> rog, ok, I think we agree here, there's no sense hand-rolling the protocol
[14:35] <rog> fwereade_: even with multiple entry points, i don't think there's a reason we couldn't use Command
[14:36] <fwereade_> rog, out point of disagreement seems to be whether stdout and stderr socket paths should be passed as part of the remote procedure call
[14:36] <fwereade_> our point^^
[14:36] <rog> fwereade_: yeah.
[14:36] <rog> fwereade_: i think that we should just go the ultra-simple route until we encounter a command that actually produces lots of output
[14:36] <rog> YAGNI...
[14:37] <fwereade_> rog, most of my arguments come back to my feeling that it's truer to the nature of a stream to let it be a stream; and that I'm not convinced that it's an unreasonable burden for the codeto bear
[14:38] <rog> fwereade_: if in doubt i'd delete 120 lines of code...
[14:41] <rog> fwereade_: i know what you mean about streams wanting to be streams, but i don't think it's worth it here.
[14:41] <fwereade_> rog, I'm not sure exactly where you're getting that number... we can certainly lose the protocol, this much is agreed
[14:42] <fwereade_> rog, that it feels inelegant and lumpen to convert a stream to a []byte to send it to another process so it can output it again as a stream
[14:43] <rog> fwereade_: i don't mind so much. it takes 0 lines of code to do that.
[14:43] <rog> fwereade_: and it's not going to make any practical difference
[14:43] <rog> fwereade_: i can't think of a way that the difference is going to be observable.
[14:44] <fwereade_> rog, hm;someone running them with --debug would like to see output more-or-less as it happens, maybe?
[14:45] <rog> fwereade_: BTW for reference, here's the server implementation using streaming with RPC: http://paste.ubuntu.com/861987/
[14:46] <rog> fwereade_: is it possible to run them at an interactive shell prompt?
[14:46] <rog> fwereade_: i thought they needed to be run within the context of a hook
[14:47] <fwereade_> rog, (1) I think hook-debug might enable something like that, but that may be FUD because Idon't recall using it
[14:47] <rog> fwereade_: (... and the client: http://paste.ubuntu.com/861989/)
[14:47] <fwereade_> (2) I'm sure there has been talk of allowing the commands to actually work outside of the hook context, but I'm not sure where to look for it
[14:48] <fwereade_> rog, or, hmm, wait; was that just getting access to relation context in non-relation hooks?
[14:48] <fwereade_> rog, sorry, that one makes more sense
[14:49] <rog> fwereade_: no, i think you were right: https://juju.ubuntu.com/docs/hook-debugging.html
[14:49] <fwereade_> rog, cool
[14:50] <rog> fwereade_: i didn't know about that
[14:50] <rog> fwereade_: but i still don't think it's sufficient justification
[14:51] <rog> fwereade_: all the in-hook commands are going to be short lived
[14:51] <rog> fwereade_: they essentially do a single zk transaction, right?
[14:51] <fwereade_> rog, I'll look through your code again, my cursory look suggested you were doing more than I was; is it that I missed significant functionality?
[14:52] <rog> fwereade_: what would happen with your code if two things executed relation-get in parallel?
[14:52] <fwereade_> rog, probably, yes, in the working-correctly case
[14:53] <fwereade_> rog, nothing too much with a moderate amount of care taken in dealing with the different client contexts' caches
[14:53] <rog> heh, most people using relation get will be doing x=$(relation-get) anyway...
[14:53] <rog> fwereade_: it seemed to dial the same socket several times. i couldn't see how the different streams were separated.
[14:54] <rog> fwereade_: (if there were concurrent calls)
[14:54] <rog> i haven't looked too closely though.
[14:54] <fwereade_> rog, ah, yes, I would appear to be on crack :/
[14:54]  * rog has another look
[14:56] <niemeyer> rog, fwereade_: That should be the end of the importer: https://codereview.appspot.com/5704056
[14:56] <rog> fwereade_: i did really like my stream-over-RPC code, BTW. the possibility has been in my head for ages. i'll save the code. but i think it's more complexity than we need.
[14:56] <fwereade_> niemeyer, cheers
[14:56] <niemeyer> Will just submit a command to run that in another CL
[14:56] <fwereade_> cool
[14:57] <rog> niemeyer: i'll have a look
[14:57] <niemeyer> fwereade_: Then, at least as far as I recall, the HTTP API we need is trivial
[14:57] <niemeyer> Which means we _migth_ have it ready by tomorrow
[14:57] <niemeyer> jcastro: ^
[14:57] <fwereade_> niemeyer, according to my fuzzy memories, that's right
[14:57] <fwereade_> niemeyer, awesome!
[14:59] <jcastro> niemeyer: woo!
[15:00] <rog> niemeyer: i'm not entirely happy about the trend towards multi-line error messages. i quite liked the approach taken by go/parser, where the error says "some error (and 27 more)" and the underlying error type provides a way to get all of them if desired.
[15:01] <niemeyer> jcastro: This doesn't mean it will be live tomorrow, by any means :)
[15:01] <niemeyer> jcastro: But you can start planning
[15:02] <niemeyer> rog: That means even the first error message may not be relevant
[15:02] <rog> niemeyer: all the error messages are relevant, no?
[15:02] <niemeyer> rog: So we end up with "branch errors" as a message
[15:02] <niemeyer> rog: Not if you strip their content :-)
[15:02] <jcastro> niemeyer: yeah this will be Good Enough
[15:03] <rog> niemeyer: i'm suggesting keeping the first error message encountered (and indicating that there are more)
[15:03] <niemeyer> rog: and I'm saying the first error message may have multiple lines
[15:03] <niemeyer> rog: Because it comes from bzr
[15:03]  * rog isn't too happy about that either
[15:04] <rog> niemeyer: messages are often written to log files, and it's useful that log file lines are consistently prefixed
[15:04] <niemeyer> rog: Heh
[15:05] <niemeyer> rog: The actual error is several orders of magnitude more interesting in a log file than its prefix
[15:05] <niemeyer> rog: If you're suggesting stripping the errors from the log file to keep it pretty, that's a big no-no
[15:05] <rog> niemeyer: agreed.  but prefixes are often used to extract relevant info.
[15:06] <niemeyer> rog: Please let's be realisitc
[15:06] <niemeyer> rog: We're not dropping the error message out of the log file.. I'm happy to have solutions, but that by itself is not one of them
[15:07] <rog> niemeyer: it looks like all the errors are logged anyway
[15:07] <niemeyer> rog: So what you are suggesting is ... ?
[15:08] <rog> niemeyer: i'm not exactly sure. i just don't like Error() returning a multi-line error :-)
[15:09] <rog> sorry
[15:36] <niemeyer> rog: The only reasonable thing I can think of is to make BranchErrors string return a "one or more branches failed to be published" message from Error
[15:38] <rog> niemeyer: as i said, i think the approach taken here (see ErrorList.Error) is a reasonable one: http://weekly.golang.org/src/pkg/go/scanner/errors.go
[15:39] <niemeyer> rog: That doesn't work in this case for the reason I explained
[15:39] <rog> niemeyer: but it won't work if some of the errors are already multi-line. perhaps bzr errors could be joined into a single line or something.
[15:39] <niemeyer> rog: Heh
[15:40] <niemeyer> rog: Let's stay on the reasonable side.. joining 10 lines in 1 won't improve the situation at all
[15:40] <rog> bzr errors are that big?
[15:40] <niemeyer> rog: Any command line tool can print an arbitrary amount of content in their standard error stream
[15:41] <rog> niemeyer: and we're treating that as "the" error message. i'm not keen. (not that i see a better approach yet though)
[15:42] <niemeyer> rog: Yeah, repeating that you're not keen isn't helpful.. I provided a suggestion. Does that help?
[15:42] <niemeyer> rog: Do you have a better one?
[15:43] <rog> niemeyer: try to work out the actual error line in the bzr output? (saving the rest for callers that want to see the whole thing)
[15:44] <rog> niemeyer: perhaps just finding the first line beginning "bzr: ERROR: " would be sufficient
[15:45] <niemeyer> rog: We still have to fall back in case we don't find it, and we still have to log the whole error message
[15:47] <niemeyer> rog: I think I'll just stick a static error message in there for now. That solves your main concern, and doesn't really change the overall behavior in any way.
[15:48] <niemeyer> We can improve that later as we find the need to
[15:48] <niemeyer> rog: Sounds good?
[15:48] <rog> niemeyer: yeah, it's better.
[15:48] <niemeyer> Cool
[15:48] <rog> niemeyer: was just looking in the bzr source to see how errors are dealt with
[15:49] <niemeyer> rog: It doesn't matter, really.. whatever heuristics we put to find an error message is still heuristics, and needs to have a fallback
[15:49] <rog> niemeyer: yeah, but the fallback for bzr could be easy - just use the first line regardless.
[15:49] <niemeyer> rog: It's human oriented text.. not a protocol, unfortunately
[15:50] <rog> niemeyer: (or all the lines joined, or whatever)
[15:50] <rog> niemeyer: but it's rare enough that it wouldn't matter, i think.
[15:51] <rog> niemeyer: it seems to me that the first line has all the relevant info - the rest is just suggestions like "However, you can get around this by doing this"
[15:51] <niemeyer> rog: See above..
[15:52] <niemeyer> rog: It's not clear what you're trying to achieve.
[15:52] <niemeyer> rog: We'll be logging the whole message to aid in solving problems..
[15:53] <niemeyer> rog: What's the problem you're trying to solve?
[15:54] <rog> niemeyer: sometimes verbosity can hide problems. to my mind, looking at the possible bzr errors, (http://paste.ubuntu.com/862070/) they look like Go errors. that's what the first line would give you. but i guess it's possible you can get several errors in a row.
[15:55] <niemeyer> rog: There are several errors in there that have \n in them.. what are you trying to show me?
[15:56] <rog> niemeyer: hmm. yeah, there are some problems.
[15:56] <rog>     _fmt = "%(target)s\n" \
[15:56] <rog>             "is not compatible with\n" \
[15:56] <rog> bah humbug
[15:56] <rog> oh well
[15:57] <niemeyer> I'll have some quick lunch.. back in a bit
[15:57] <rog> just strip out \n...
[15:57] <rog> niemeyer: ok
[15:57] <rog> niemeyer: enjoy
[15:57] <niemeyer> rog: Stripping out \n == huge message == what is rog trying to do?
[15:57]  * niemeyer steps out for real
[16:10] <rog> niemeyer: yeah, it's a difficult call. but on balance i think i'd prefer an error message that conformed to the usual one-line convention, even if the one line was very long, to one that didn't.
[16:34] <hazmat> do we log this channel?
[16:34] <hazmat> jcastro, i thought we had that setup.. but i don't see the logger/mup around
[16:42] <rog> hazmat: if we don't, we should...
[16:43] <hazmat> i don't really have any insight into getting _mup_ on here.. niemeyer ?
[16:44] <jcastro> hazmat: we did, it must have gone missing, I'll check
[17:15] <niemeyer> rog: I'd rather have something that is readable instead. Let's keep it as-is until we find a better scheme.
[17:15] <rog> niemeyer: fair enough.
[18:00] <fwereade__> bother it's 7, bbl if I can
[18:36] <niemeyer> The world is falling!
[18:36] <niemeyer> I mean.. it's raining..
[18:43] <niemeyer> The volume of water falling here is amazing..
[18:46] <jimbaker> niemeyer, sounds like the snowstorms we sometimes get here. best appreciated when it comes suddenly during a 22 deg C day in the spring, while wearing shorts
[18:47] <rog> i like rainstorms
[18:47] <rog> i'm off for the night, BTW. i smell spag boll!
[18:47] <rog> see ya tomorrow
[18:47] <niemeyer> rog: Cheers! Enjoy!
[19:42] <andrewsmedina> why Go port dont have providers module?
[19:57] <niemeyer_> andrewsmedina: It's called environs
[19:57] <niemeyer> andrewsmedina: After some back and forth we ended up renaming it
[19:57] <niemeyer> andrewsmedina: Well.. consolidating might be a better way to put it
[19:57] <niemeyer> andrewsmedina: Python has both environments and providers
[19:57] <niemeyer> andrewsmedina: Go has only environments
[19:58] <andrewsmedina> niemeyer: hmm
[19:59] <andrewsmedina> niemeyer: I updated gozk to use the last gocheck version
[20:00] <niemeyer> andrewsmedina: Ah, nice.. do you want to propose it?
[20:01] <andrewsmedina> niemeyer: I'm at work now
[20:01] <niemeyer> andrewsmedina: Ah, super
[20:02] <andrewsmedina> niemeyer: tonight I propose
[20:02] <niemeyer> andrewsmedina: Super
[20:02] <niemeyer> andrewsmedina: What's you daily project, btw?
[20:02] <andrewsmedina> niemeyer: I work at globo.com
[20:03] <niemeyer> andrewsmedina: Ah, right.. what project there?
[20:03] <niemeyer> andrewsmedina: (if that's public info)
[20:03] <andrewsmedina> niemeyer: now, I'm in working in a private PaaS using Openstack + juju + cloudfoundry
[20:03] <niemeyer> andrewsmedina: Hah, nice.. I heard about those. ;-)
[20:03] <andrewsmedina> niemeyer: I work with flaviamissi
[20:04] <flaviamissi> :)
[20:06] <niemeyer> flaviamissi: Buenas :)
[20:06] <andrewsmedina> niemeyer: I met you at pyconbrasil 2007 in joenvile
[20:07] <flaviamissi> niemeyer: hi!
[20:08] <niemeyer> andrewsmedina: Wow.. really? My memory sucks..
[20:08] <andrewsmedina> niemeyer: I'm a django guy
[20:09] <niemeyer> I miss Dorneles..
[20:09] <andrewsmedina> niemeyer: me too =/
[20:09] <andrewsmedina> niemeyer: In 2007 I was a only brazilian django guy at pycon
[20:09] <flaviamissi> andrewsmedina: y u no work?!
[20:10] <flaviamissi> andrewsmedina: HAEUheauhEAhAEAE
[20:10] <niemeyer> flaviamissi: Let me know if you need anything.. happy to see you guys using juju there
[20:10] <andrewsmedina> flaviamissi: oO
[20:11] <flaviamissi> niemeyer: sure! you'll hear a lot from us, or read... whatever
[21:07] <hazmat> hmm.. adding the alias expansion to the scheduler is harder than i thought, it really wants to reduce redundant events.. and the expansion is redundant.
[21:08] <niemeyer> hazmat: It's the machine raising against us!
[21:21] <niemeyer> Time for some outsiding.. back later
[21:43] <hazmat> niemeyer, i'm thinking its time to revisit the notion that hook errors on relation events, drop the event. i'm starting to think we should keep/replay the event post resolved
[21:43] <hazmat> it doesn't feel quite sane otherwise
[21:54] <hazmat> sigh.. feels like there are a couple of bugs here
[23:38] <hazmat> jimbaker, what's the rationale for juju do
[23:39] <hazmat> on its face it seems highly suspect to me
[23:39] <jimbaker> hazmat, i do have some use cases in the proposal that are derived from it
[23:39] <jimbaker> hazmat, i certainly would entertain any suggestions for alternatives that enable out-of-band hook exec
[23:40] <hazmat> jimbaker, your confusing the client with hooks calling other hooks
[23:40] <hazmat> ie. the bugs wasn't about the user invoking arbitrary hooks
[23:40] <jimbaker> hazmat, i address that in a separate section
[23:40] <hazmat> k
[23:41] <jimbaker> it is certainly ok with me if we don't implement. to quote, i'm not absolutely sure of anything...
[23:41] <jimbaker> except perhaps the well-ordered principle ;)
[23:48] <hazmat> yeah.. its not on the table.. imo.. its insane.. but i haven't finished reading.. so i'll defer discussion till then
[23:53] <jimbaker> hazmat, please certainly put that feedback in the email
[23:53] <jimbaker> then we can definitively capture that it's a bad idea
[23:53] <hazmat> i'm just reviewing in reitveld
[23:54] <jimbaker> hazmat, sure, that's a good place to review, but the high-level feedback needs to be on the mailing list
[23:54] <jimbaker> otherwise juju stakeholders are unlikely to see it
[23:55] <hazmat> i think you've lost most of the relevant stake holders.. outside of the first paragraph
[23:55] <hazmat> the rest is effectively spec merge review
[23:57] <jimbaker> hazmat, ok, i'm just trying to follow the process in https://lists.ubuntu.com/archives/juju/2011-November/000931.html
[23:58] <hazmat> jimbaker, fair enough
[23:58] <hazmat> jimbaker, and thanks for doing so
[23:58] <jimbaker> hazmat, no
[23:58] <jimbaker> problem