00:03:25  * TheJHquit (Ping timeout: 248 seconds)
00:03:44  * jbuezajoined
00:14:19  <creationix>rphillips: what does your systems binding do?
00:14:27  <creationix>*systemd
00:50:41  * mmalecki[busy]changed nick to mmalecki
00:54:14  * jelliottquit (*.net *.split)
00:54:14  * leviquit (*.net *.split)
00:58:20  * jelliottjoined
00:58:20  * levijoined
01:02:02  <rphillips>creationix: systemd binding?
01:05:45  * xmingquit (Ping timeout: 272 seconds)
01:12:42  * mmaleckiquit (Quit: Reconnecting)
01:13:00  * mmaleckijoined
01:26:26  <CIA-22>Ryan Phillips master * r2808f7f / (2 files): disable the multicast test for now - http://git.io/MK-HGQ
01:26:54  <creationix>hmm must have of been philips_
01:26:59  <creationix>oops
01:27:03  <rphillips>ah
01:27:09  <rphillips>he wrote an init script iirc
01:27:52  <rphillips>https://github.com/racker/virgo/commit/36147a6b3267cb495b5792fdabc5dfb7e5ca5b8b
01:27:53  <rphillips>yeah
01:28:49  * travis-cijoined
01:28:49  <travis-ci>[travis-ci] luvit/luvit#436 (master - 2808f7f : Ryan Phillips): The build passed.
01:28:49  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/255e8885668d...2808f7f73d45
01:28:49  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/2290579
01:28:49  * travis-cipart
01:43:18  * joshthecoderquit (Quit: Leaving...)
01:48:49  * mmaleckiquit (Ping timeout: 272 seconds)
02:07:01  <creationix>rphillips: I'm playing with continuable style async functions
02:07:18  <creationix>It's like lightweight promises
02:07:33  <creationix>halfway between simple callbacks and promises
02:23:02  <Spion>wrap makes a coroutine?
02:32:44  <creationix>Spion: which wrap?
02:33:20  <creationix>continuable syntax works nicely in coffescript https://gist.github.com/1b47cba9f3a066147966
02:33:29  <creationix>I wonder how moon script will handle it
02:34:34  <Spion>the wrap provided by fiber
02:35:17  <Spion>in the api design question gist :)
02:36:32  <Spion>the simplest API I've seen so far (node/coffeescript/otherwise) is streamline's - if something similar to that can be replicated without a preprocessor I'd love to use it :)
02:38:10  <Spion>omit the callback and you get a promise function that "yields" when called with _; use a _ instead of the callback to yield immediately; use a normal callback for normal behaviour
02:45:41  <Spion>something like omitting the callback and getting a promise function, when called with a parameter its considered a callback (continuable syntax), when called without it yields. best of all worlds?
02:45:47  <creationix>Spion, yes, with continuable syntax, you can get streamline-like syntax without a preprocessor
02:45:52  <creationix>that's what I'm working on right now
02:45:57  <Spion>most awesome
02:45:58  <Spion>:D
02:46:11  <creationix>wrap isn't going to work since it requires wrapping every function before using in every coroutine
02:46:17  <Spion>yeah :|
02:46:20  <creationix>the new fiber module will have a wait function
02:46:32  <creationix>so assuming that fs is in continuable style
02:47:03  <Spion><3
02:47:25  <creationix>fs.readFile(path)(function (err, contents) end) will become contents = wait(fd.readFile(path))
02:47:37  <Spion>exactly what I was thinking
02:47:40  <creationix>no need to modify or wrap readFile
02:48:06  <Spion>just the call
02:48:26  <creationix>also, if moon script works like coffee script, using continuables without coroutines will be pretty too
02:48:36  <creationix>though it's not tool bad in vanilla lua
02:48:48  <creationix>Spion: https://gist.github.com/1b47cba9f3a066147966
02:51:10  <creationix>I think this coroutine syntax is awesome enough to make it work converting luvit to continuable syntax
02:51:17  <creationix>it will break all code though
02:51:27  <creationix>s/work/worth/
02:51:41  <creationix>rphillips: what do you think, would that kind of API change kill you guys?
02:52:08  <creationix>mostly it's replacing ", callback" with ")(callback" in your calls
02:52:25  <Spion>isn't it possible to have it both ways?
02:52:30  <Spion>:D
02:52:38  <creationix>which "both"
02:52:46  <creationix>I'm not supporting two versions of all functions
02:53:54  <creationix>rphillips: and in function definitions replacing ", callback) {" with ") { return function (callback) {"
02:54:23  <Spion>well, its easy to convert them to old style anyway
02:54:35  <creationix>sure, anyone can wrap
02:54:48  <creationix>but I don't want most people wrapping
02:54:57  <Spion>no, I mean, to make functions that work both ways after wrapping them.
02:55:05  <Spion>omit the callback and you get a function
02:55:12  <Spion>put the callback in and you get old behaviour
02:55:24  <creationix>that requires too much boilerplate
02:55:32  <creationix>the double function is bad enough
02:57:00  <rphillips>hmm
02:57:18  <rphillips>this would change a lot of stuff for us
02:57:30  <creationix>mostly superficial though
02:57:52  <creationix>and you could delete all your arguments surgery code when you want optional arguments before the callback
02:58:07  <creationix>I tried to push this style on node back when we were removing promises years ago
02:58:15  <creationix>I wish I had just put it in luvit from the start
02:58:50  <rphillips>we are under the gun for the product we are working on.
02:58:57  <creationix>rphillips: if it's a deal-breaker let me know. If you just need help manually changing stuff I can help with that
02:59:18  <rphillips>creationix: can you send an email to the luvit list?
02:59:24  <creationix>sure
02:59:31  <rphillips>and i'll get pquerna and philips_ to chime in
03:01:17  * xmingjoined
03:13:23  <creationix>https://groups.google.com/d/topic/luvit/GkakgfcaNDQ/discussion
03:13:51  <creationix>This change and the other two proposed changes will make writing web apps in luvit worlds easier!
03:14:33  <creationix>Imagine creating a coroutine per http request and doing all your app logic using sync-style code
03:15:13  <creationix>it will be as easy as php, but faster than node (I think)
03:19:47  <creationix>also parallel work would be easy too. wait could accept multiple continuables and wait till they all return
03:20:15  <creationix>file1, file2, file3 = wait(fs.readFile("file1"), fs.readFile("file2", fs.readFile("file3"))
03:43:00  <Spion>https://gist.github.com/3548825
03:43:07  <Spion>its pretty ugly but its backward-compatible
03:43:53  <Spion>its also probably not really good code, I was just trying to illustrate it
03:46:08  <Spion>also, i bet the performance would suck
03:48:13  <Spion>also it would fail when the callback isn't the last parameter and the parameter after it is also a function
03:48:29  <Spion>infact I bet that the reverse wrapper is easier
03:50:35  <Spion>just throwing stuff on the table :D
03:51:05  <Spion>no pun intended
03:55:28  <Spion>of course everyone would need to wrap() their functions, that will drive people insane
03:55:34  * Spionhides
03:56:23  <creationix>yeah, I'm not wrapping
03:56:48  <Spion>not function callers, but function writers, yeah
03:57:55  <creationix>yep, users of luvit write and call async functions all the time
03:57:59  <creationix>I want both to be painless
03:58:20  <creationix>the double function boilerplate is somewhat annoying, but I think it's acceptable
04:22:51  <creationix>Spion: alright, here is now the new fiber module is used https://gist.github.com/4af628ad6a8d02ad0f65
04:23:42  <creationix>"wait" returns all the arguments passed to the callback, "await" is short for "auto wait" it strips off the first arg and throws it as an error if it's truthy
04:24:51  <creationix>as soon as I fix a bug where the fiber module blows up when the callback is called synchronously, I'll publish this working example as a luvit example
04:51:29  * kristatejoined
04:58:37  <CIA-22>Tim Caswell master * rb52c6fc / (4 files in 2 dirs): Add new stream, new fiber, and new continuable examples - http://git.io/qNxFeQ
04:59:22  <creationix>it works!
04:59:24  <creationix>https://github.com/luvit/luvit/blob/b52c6fc1f47c20cb1b209739c7809af6fce75561/examples/stream/test.lua#L34-42
05:00:14  <creationix>22 lines for callback based vs 7 lines for await based
05:01:01  * travis-cijoined
05:01:01  <travis-ci>[travis-ci] luvit/luvit#437 (master - b52c6fc : Tim Caswell): The build passed.
05:01:01  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/2808f7f73d45...b52c6fc1f47c
05:01:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/2291516
05:01:01  * travis-cipart
05:08:39  <CIA-22>Tim Caswell master * r950c457 / (examples/stream/modules/file.lua examples/stream/test.lua): Tidy up new stream example - http://git.io/S7bCfA
05:11:25  * travis-cijoined
05:11:25  <travis-ci>[travis-ci] luvit/luvit#438 (master - 950c457 : Tim Caswell): The build passed.
05:11:25  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/b52c6fc1f47c...950c457b0e25
05:11:25  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/2291552
05:11:25  * travis-cipart
05:19:47  * dvv1joined
05:22:36  <creationix>I think the repl should run in a fiber
05:22:41  <creationix>with wait and await available
05:22:55  <creationix>then I'd never need to use *Sync functions again
05:56:26  * `3rdEdenjoined
06:02:41  * aliemjoined
06:29:08  * TheJHjoined
09:48:33  * jbuezaquit (Quit: jbueza)
09:50:31  * xmingquit (Changing host)
09:50:31  * xmingjoined
10:29:57  * mmaleckijoined
10:33:29  * kristatequit (Remote host closed the connection)
10:33:51  * kristatejoined
11:48:47  * damjanquit (Quit: ZNC - http://znc.in)
11:50:13  * damjanjoined
11:53:06  * damjanquit (Read error: Connection reset by peer)
11:54:35  * damjanjoined
12:04:59  * damjanquit (Quit: ZNC - http://znc.in)
12:06:28  * damjanjoined
12:19:25  * CIA-22quit (Ping timeout: 252 seconds)
12:25:59  * CIA-16joined
12:45:34  <creationix>dvv: luau is interesting
12:45:43  <creationix>*luauv
12:46:46  <creationix>I don't like how it does sync I/O if you're not in a coroutine
12:52:57  <dvv1>me too
12:53:20  <dvv1>but the way to determine coro is elegant
12:55:45  <dvv1>otoh, sync versions could roughly replace standard Lua io module
12:59:23  <dvv1>what repells me from luauv is c++ism which pulls giant libc++
13:02:10  <creationix>is there a way to tell if you're in a coro from lua?
13:02:17  <creationix>I see they are using the C API to tell
13:02:40  <creationix>I want user-created functions to work seamlessly with fibers as well
13:03:02  <creationix>with continuables, any continuable can be waited on
13:03:17  <creationix>and a continuable is nothing more than a function that takes a single callback as arguments
13:04:09  * `3rdEdenchanged nick to `3E|Shop
13:18:16  * CIA-16quit (Ping timeout: 244 seconds)
13:23:17  * CIA-19joined
14:27:02  * mmaleckichanged nick to mmalecki[food]
14:27:34  <rphillips>good morning
14:28:47  <creationix>morning
14:29:12  <creationix>rphillips: so is it fair to say that you guys have a lot less resources to contribute to luvit than you used to?
14:30:24  <creationix>as exciting as these changes are, I don't want to completely alienate virgo and leave you on an unsupported fork
14:32:22  <creationix>hnakamur: heh, I just remembered you ported my Do library to luvit. Does this mean you like the new continuable syntax as well?
14:33:02  <creationix>rphillips: also we don't have to drop support for the node-clone api virgo uses. All my experiments have been in pure lua without changing core at all.
14:33:19  <hnakamur>well i don't have written enough sample codes to get feels
14:33:47  <creationix>hnakamur: did you see how nicely it works with coroutines?
14:34:09  <rphillips>creationix: there have only been two of us working on our agent and luvit
14:34:12  <rphillips>plus paul
14:34:14  <hnakamur>no, i haven't yet.
14:34:50  <creationix>rphillips: so you guys are just plain awesome and get a lot done :)
14:34:57  <hnakamur>i don't think i like this https://github.com/hnakamur/luvit-do/blob/master/tests/test-chain.lua#L97
14:35:10  <creationix>hnakamur: https://github.com/luvit/luvit/blob/master/examples/stream/test.lua#L34-43
14:35:28  <creationix>hnakamur: yeah, I don't like do.chain either
14:36:12  <hnakamur>coroutine version looks simple to me.
14:36:29  <creationix>hnakamur: and it would be easy to make it support multiple parallel calls
14:36:46  <hnakamur>oh, that would be nice.
14:36:56  <creationix>file1 , file2 = await(fs.readFile("file1"), fs.readFile("file2"))
14:37:29  <creationix>then you wouldn't even need a library like do if you were using coroutines
14:38:20  <hnakamur>it feels to me coroutines are easier to read.
14:38:32  <creationix>much, though a little harder to reason about
14:38:35  <hnakamur>wonder how performance is like with coroutines, though.
14:38:59  <creationix>I don't get that pretty syntax entirely for free, there is a bit of logic behind it https://github.com/luvit/luvit/blob/master/examples/stream/modules/wait.lua
14:39:11  <creationix>we'll have to test it to find out how it performs
14:39:20  <creationix>but after asking mike pall, I don't think it will be that bad
14:39:30  <creationix>I was surprised how little ram a coroutine uses
14:39:44  <creationix>just a few bytes if I remember corectly
14:40:12  <creationix>my next step is to port my "web" module to use continuables
14:40:20  <creationix>and bench it using callbacks and coroutines
14:40:58  <hnakamur>it seems creating coroutines are fast. https://gist.github.com/3505055
14:41:16  <hnakamur>cf. creating processes in erlang https://gist.github.com/3505035
14:41:50  <hnakamur>i don't know context switch cost in coroutines yet, though.
14:42:00  <creationix>wow, almost 7x faster for a million of them
14:42:13  <creationix>it makes sense though
14:42:19  <creationix>coroutines don't do as much as erlang processes
14:42:36  <creationix>being green threads, the context switch shouldn't be that bad
14:42:44  * `3E|Shopchanged nick to `3rdEden
14:42:56  <creationix>I guess it depends how deep the stacks get
14:43:05  <hnakamur>that's nice. if coroutines scale enough, i'd prefer coroutines.
14:43:46  <creationix>so my goal in all this API innovation is to build the ideal base for an awesome web framework
14:44:08  <creationix>the framework would bundle all sorts of middleware for handling cookies, form uploads, http auth, etc
14:44:22  <creationix>and it would put user code in an implicit coroutine for each request
14:44:33  <creationix>so apps could be written using sync style code
14:44:53  <creationix>and there wouldn't be any uncaught exceptions as long as the user stuck to the coroutine style
14:45:18  <creationix>my only unsolved problem is how to clean up resources in case of error
14:46:45  <creationix>I guess the framework could provide an api where user code registers cleanup code in case of trouble. It's not automatic, but it's like try..catch..finally
14:47:28  <kristate>creationix: hmm, sounds more tricky than it has to be
14:48:03  <creationix>if I found a way to get at the currently running coroutine, then I could just instrument resource opening functions (like fs.open) to register the fd with the coroutine. If the coro dies, it could auto-close the file descriptors
14:48:11  <creationix>making the user manually register cleanup is a mess
14:48:19  <kristate>today on lev, all read() calls now return cBuffers
14:48:23  <kristate>https://github.com/connectFree/lev
14:48:32  <creationix>I'll bet it's fast
14:48:52  <kristate>we have not benchmarked it against luvit yet
14:49:06  <kristate>xming is working on cmake for lev right now
14:49:14  <creationix>nice
14:49:35  <creationix>my http layer should be able to run on top of lev
14:49:36  <xming>yeah I ran to the other side :D
14:49:44  <creationix>xming: it's all the same
14:49:56  <kristate>creationix: cool, you can try it out on top of lev
14:50:05  <creationix>kristate: what callback style do you want?
14:50:25  <kristate>depends on if we want to keep emit-style callbacks
14:50:34  <creationix>node-style callback-last like luvit has now, luauv implicit coroutines, or my new proposed continuable style
14:50:46  <creationix>"emit-style"?
14:50:59  <kristate>emit("data", data)
14:51:11  <creationix>I'm trying to get away from that
14:51:21  <creationix>if your stream interface matches mine, then we'll be able to share a ton of libraries
14:51:40  <kristate>emit is nice in the sense that it can bubble-up over instance
14:51:42  <kristate>s
14:51:53  <kristate>that is, we can subclass objects and easily handle events
14:52:01  <creationix>yeah, and you can always layer an emitter on top of my new streams
14:52:13  <creationix>but the core interface is just a continuable method
14:52:16  <xming>creationix: yeah
14:53:03  <kristate>like hnakamur mentioned, we need to benchmark the impact of context switches via coroutines
14:53:03  <creationix>you could even switch your core to be select based instead of using C callbacks and the stream API could stay the same
14:53:15  <kristate>if they are not required, it is best to avoid them as they are overhead
14:53:27  <creationix>kristate: right, I'm making the emitter part optional
14:53:32  <creationix>the less parts the better
14:53:46  <creationix>a readable stream is any table with a :read()(callback) method
14:53:57  <creationix>and a writable stream is any table with a :write(chunk)(callback) method
14:54:30  <creationix>and baked into when the callback gets called and with what values encodes "data" "error" and "end" events
14:54:32  <kristate>hmm, I don't like that we have to call read()
14:54:42  <kristate>at the moment, buffer management, etc is all handled in the background
14:55:01  <creationix>:read() shouldn't preclude that
14:55:12  <creationix>if anything is helps prevent excessive buffering
14:55:27  <creationix>node's readable stream that emits "data" and "end" events is a royal pain
14:55:43  <kristate>I am not sure if there is such a thing as excessive buffering
14:55:57  <kristate>if a read() event occurs, it should be read
14:56:06  <creationix>I mean, suppose I write an http server
14:56:19  <creationix>and I want to serve a 1gb movie to my tablet over 3g
14:56:32  <creationix>clearly the read from the disk is going to be faster than the upload to the tablet
14:56:50  <creationix>so to properly handle this and not end up buffering the 1gb file in ram, I need to throttle the read stream
14:57:03  <hnakamur>i wonder if we can avoid callback from C. http://luajit.org/ext_ffi_semantics.html says "Callbacks are slow!"
14:57:08  <creationix>with "data" events, I have to manually call :pause() and :resume()
14:57:28  <creationix>hnakamur: you'd have to write a layer on top of libuv or use another library
14:57:33  <hnakamur>So maybe we can queue the data in C, and lua code pulls that.
14:57:33  <creationix>hnakamur: that's something I wanted to try
14:57:45  <creationix>hnakamur: exactly
14:58:03  <kristate>ah, but in that event you don't have to pause fs? you can simply seek the file
14:58:27  <creationix>kristate: right, but with the current emitter api, you have to pause
14:58:33  <creationix>and what if the input is a socket
14:58:45  <creationix>then you do have to pause and resume the socket
14:58:54  <creationix>but I don't want user-level code having to mess with that
14:59:02  <creationix>I'd prefer they just ask for data when they are ready to handle it
14:59:23  <kristate>sure, that's why there are events for that.
15:00:03  <creationix>so here is the current stream interface (or the node one we copied) http://nodejs.org/api/stream.html
15:00:32  <creationix>my proposed interface is about 1/4 the size
15:00:44  <creationix>and very coroutine friendly
15:01:27  <creationix>repeat local chunk = input:read(); output:write(chunk); until not chunk
15:01:38  <creationix>full streaming with proper source throttling
15:01:50  <creationix>looks just like the blocking I/O equivalent
15:02:17  <creationix>I guess what I'm missing is "close" and "pipe" events
15:02:26  <creationix>but I don't think those are part of the stream API
15:03:15  <creationix>I do have readable's "data", "end", "error" and writable's "drain" and "error" events encoded
15:03:33  <kristate>right, but why reimplement blocking sockets?
15:03:43  <creationix>because it's not blocking
15:03:49  <creationix>it's just as easy to use as blocking sockets
15:04:56  <creationix>kristate: are you on the mailing list? I explained the pros to this approach there
15:05:09  <kristate>Not yet
15:05:18  <kristate>email is my weakness
15:05:29  <creationix>https://groups.google.com/d/topic/luvit/wFsudgNyFH8/discussion and https://groups.google.com/d/topic/luvit/GkakgfcaNDQ/discussion
15:09:12  <xming>email is for old people, like me
15:40:51  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
16:14:01  * joshthecoderjoined
16:19:58  * luastonedjoined
16:26:00  <pquerna>.
16:26:55  <pquerna>creationix: i'm confused whats going on kinda
16:27:58  <pquerna>creationix: honestly at this point, if there were massive changes to how all of luvit works, we would probally edge towards a fork
16:28:35  <creationix>pquerna: good to know
16:28:54  <creationix>basically I'm trying to learn from node's mistakes while taking advantage of lua language features
16:29:11  <creationix>to make luvit a better node, not just a node clone with lower memory usage
16:29:25  <pquerna>right, and there is definately value there; but for us... we need to be moving our agent from more r&d to more prod this fall
16:29:32  <kristate>pquerna: https://github.com/connectFree/lev
16:29:36  <creationix>I can leave all the old libraries working and supported
16:30:03  <creationix>it's all just lua code anyway
16:30:09  <creationix>I don't plan on messing with the C bindings
16:30:19  <creationix>you could just bundle the old fs.lua in with virgo
16:30:28  <pquerna>sure
16:30:36  <creationix>I'll probably name the new one file so as to not confuse anyone
16:30:42  <creationix>and the new http module will be "web"
16:32:00  <creationix>mixing new and old styles will be a problem
16:32:15  <creationix>but other than virgo, nobody else uses luvit in production as far as I know
16:35:39  <creationix>pquerna: ok so what if I pushed most the lua libraries in luvit to userspace. You could then own and maintain the current APIs
16:35:47  <creationix>would that be too much burden?
16:36:30  <pquerna>mmm, it depends if we can really make the C to Lua bindings super stable
16:36:37  <pquerna>i agree they don't change much today;
16:36:50  <pquerna>the c to lua bindings being super stable is somethign we want for the agent regardless
16:37:15  <creationix>hmm, about that
16:37:25  <creationix>I do want to experiment with a pull based C api
16:37:47  <creationix>but that's mostly moving dispatching to lua
16:37:57  <creationix>whoever is using the lua dispatcher code should see the same API as before
16:38:31  <creationix>so as long as I provide the same callback-based api as what uv_native currently provides, we should be good?
16:38:37  <creationix>be it C or lua
16:41:37  <pquerna>so, I mean, if it can work, that'll be awesome; but realistically for us, we are focused on stabilization and deployment to 100,000 servers across a dozen platforms in the next few months; I don't think its a good time for us to really track experiments in this realm. If this was 6-9 months ago... we could follow along.... but... mostly bad timing in this regards
16:42:00  <creationix>that's fine, I was just wondering
16:42:40  <creationix>I'll keep in mind that if I break compatibility, I'll lose rackspace's support.
16:42:59  <creationix>in the short-term, I'll probably just continue writing user-space libraries and frameworks
16:43:45  <pquerna>k
16:44:11  <creationix>once my new libraries are production quality, we'll talk about removing the old stuff from core
16:44:18  <creationix>and bumping it to userspace
16:44:33  <pquerna>we can handle small changes in abi if it helps, but changing everything to fibers or what not... just not gonna happen for us right now :)
16:44:50  <creationix>right, small tweaks
16:44:57  <creationix>like make fs.open only accept integers for mode
16:45:02  <pquerna>sure
16:58:26  * mmalecki[food]changed nick to mmalecki
16:58:55  * aliemquit (Remote host closed the connection)
17:32:22  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
17:40:44  * CIA-19quit (Ping timeout: 244 seconds)
17:47:45  * `3rdEdenjoined
17:48:04  * CIA-12joined
17:54:33  * CIA-12quit (Ping timeout: 265 seconds)
17:56:04  <creationix>looks like I can make "wait" and "await" globals
17:56:10  <creationix>that work on any coroutine
17:56:16  <creationix>but the question is, is that a good idea?
18:06:50  * CIA-15joined
18:12:20  <hnakamur>well, we should avoid too many globals. you can say local wait = require('foo').wait anyway, can't you?
18:40:23  * `3rdEdenquit (Quit: Leaving...)
18:41:09  * CIA-15quit (Ping timeout: 244 seconds)
18:42:24  * joshthecoderjoined
18:48:58  * CIA-13joined
18:56:43  * CIA-13quit (Ping timeout: 272 seconds)
19:00:06  * CIA-18joined
19:09:51  * CIA-18quit
19:13:05  * CIA-19joined
19:20:04  * kristatequit (Ping timeout: 246 seconds)
19:32:49  * CIA-19quit (Ping timeout: 252 seconds)
19:38:42  * CIA-13joined
19:42:20  * `3rdEdenjoined
19:42:23  * `3rdEdenquit (Remote host closed the connection)
20:52:38  <creationix>power outage, I'm back now
20:52:47  <creationix>hnakamur: yep, that's what I did
20:52:55  <creationix>(while the power was out)
21:25:46  * luastonedquit (Quit: Leaving.)
21:38:06  * elguapo99quit (Quit: ChatZilla [Firefox 14.0.1/20120713134347])
22:34:55  * elguapo99joined
22:39:52  * elguapo99quit (Quit: ChatZilla [Firefox 14.0.1/20120713134347])
22:40:18  * elguapo99joined
22:51:08  * joshthecoderquit (Quit: Leaving...)
23:01:49  * TheJHquit (Ping timeout: 252 seconds)
23:14:00  * joshthecoderjoined
23:39:45  * joshthecoderquit (Quit: Leaving...)