| 00:00:00
| * ircretary | quit (Remote host closed the connection) |
| 00:00:08
| * ircretary | joined |
| 00:02:21
| * wolfeidau | quit (Remote host closed the connection) |
| 00:13:22
| * kesla | quit (Ping timeout: 246 seconds) |
| 00:20:16
| * jibay | quit (Remote host closed the connection) |
| 00:25:16
| * gwenbell | quit (Ping timeout: 246 seconds) |
| 00:32:25
| * thlorenz | joined |
| 00:52:23
| * yorick | quit (Remote host closed the connection) |
| 00:53:31
| * AvianFlu | joined |
| 01:01:51
| <Domenic_> | If anyone is interested in the future of file APIs for the web, there's a really-quite-interesting thread in public-script-coord right now. http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html /cc creationix mbalho |
| 01:02:11
| <Domenic_> | I am pushing for a minimal core that users can build off of but am somewhat alone. |
| 01:03:07
| * kumavis | joined |
| 01:04:17
| * no9 | quit (Quit: Leaving) |
| 01:05:03
| <mbalho> | Domenic_: is that not a known position across all working groups? |
| 01:05:32
| <Domenic_> | mbalho: that is a guiding philosophy *in theory*, but they are having trouble applying it in practice. |
| 01:05:41
| <mbalho> | Domenic_: imo filesystem api doesnt need to exist, it can be implemented on top of indexeddb in userland |
| 01:06:11
| <mbalho> | Domenic_: filereader needs work though |
| 01:06:33
| <Domenic_> | mbalho: haha apparently standards groups have been saying that for a long time but nobody believes them so they are implementing a real fs api |
| 01:07:02
| <mbalho> | Domenic_: :( |
| 01:08:00
| <Domenic_> | we are trying to get them to create a usable streams abstraction as part of this. isaacs has been very helpful so far. they seem to be listening, somewhat. |
| 01:08:28
| <mbalho> | Domenic_: ok so literally the *only* requirement for a good streams api is: receive data in chunks |
| 01:08:46
| <mbalho> | Domenic_: everything else is optional |
| 01:08:51
| <Domenic_> | mbalho: well we'd want backpressure and such too. |
| 01:09:04
| <mbalho> | Domenic_: that would be nice |
| 01:09:13
| <mbalho> | Domenic_: but IMO receive data in chunks is highest priority |
| 01:09:26
| <mbalho> | Domenic_: because you cant receive data in chunks in xhr2 today |
| 01:09:34
| <Domenic_> | yeah |
| 01:09:56
| <mbalho> | Domenic_: so as long as it has that i dont really care what else is in there |
| 01:10:25
| <mbalho> | Domenic_: filereader also cant pause a read, so backpressure would be good there |
| 01:10:59
| <mbalho> | Domenic_: you have to read a range, then kill it and start a new filereader at the next byte range you want when you wanna read more data, its crazy |
| 01:11:51
| <mbalho> | Domenic_: and xhr2.responseType = 'arraybuffer' emits readystate 3 one time, at the end of the request. the response body isnt accessible to JS before that, it just buffers the whole thing into one chunk |
| 01:12:21
| <mbalho> | Domenic_: responseType text emits readystate 3 multiple times but it isnt in chunks, it is still 1 huge response string, but at least you can get at the data before the request finishes |
| 01:12:36
| <mbalho> | Domenic_: so in light of how crappy the current apis are I just wanna see 'receive data in chunks' |
| 01:12:44
| <Domenic_> | haha gotcha :) |
| 01:13:26
| <Domenic_> | currently streams are looking something like `Promise<ArrayBuffer | EOFSignalProbablyUndefined> read(n)`. |
| 01:13:48
| * AvianFlu | quit (Remote host closed the connection) |
| 01:13:57
| <mbalho> | with an event that tells you when its readable? |
| 01:14:06
| <mbalho> | what does the <> syntax mean in standards land |
| 01:14:12
| <mbalho> | what it emits? |
| 01:14:35
| <Domenic_> | more or less, yeah it's just generics. Promise for either an ArrayBuffer or some type of EOF signal |
| 01:14:48
| <Domenic_> | They haven't gotten as far as a readable event yet |
| 01:14:50
| <mbalho> | cool that seems pretty simple |
| 01:14:50
| * wolfeidau | joined |
| 01:15:08
| <Domenic_> | yay |
| 01:17:43
| * AvianFlu | joined |
| 01:21:13
| * wolfeidau | quit (Read error: Connection reset by peer) |
| 01:21:37
| * kumavis | quit (Quit: kumavis) |
| 01:22:19
| * wolfeidau | joined |
| 01:22:43
| * kumavis | joined |
| 01:28:22
| * kumavis | quit (Quit: kumavis) |
| 01:31:15
| <ricardobeat> | Domenic_: any idea if these APIs will support callbacks besides promises? or are things heading to promises everywhere? |
| 01:32:23
| * AvianFlu | quit (Remote host closed the connection) |
| 01:32:31
| <mbalho> | callbacks arent fancy enough |
| 01:32:46
| <mbalho> | i was thinking of naming all of my callbacks promise |
| 01:32:57
| <mbalho> | like fs.readFile(function promise(err, data){}) |
| 01:33:17
| * AvianFlu | joined |
| 01:33:24
| <mbalho> | to dress them up a little |
| 01:33:30
| <mbalho> | putting the prom in promise |
| 01:36:11
| <ricardobeat> | or yet, what will happen to existing APIs after ES7 if this happens? they can't change to start returning promises |
| 01:36:44
| <mbalho> | Domenic_: id like to hear an argument as to why a filesystem api has to be native and cant be done in pure js |
| 01:37:20
| <jesusabdullah> | the thing is: promises still use callbacks |
| 01:37:21
| <jesusabdullah> | :) |
| 01:37:24
| <ricardobeat> | mbalho: apparently they intend for it to access the actual file system in the future |
| 01:37:49
| <mbalho> | really? |
| 01:38:29
| <ricardobeat> | "it is expected that this API will eventually also be used for |
| 01:38:30
| <ricardobeat> | accessing real filesystems eventually" |
| 01:38:49
| * wolfeidau | quit (Read error: Connection reset by peer) |
| 01:38:49
| <mbalho> | 'expected' 'eventually' hah |
| 01:39:01
| <ricardobeat> | eventually*2 |
| 01:40:31
| * wolfeidau | joined |
| 01:42:25
| <ricardobeat> | jesusabdullah: oh well |
| 01:43:56
| * mcollina | joined |
| 01:44:05
| <ricardobeat> | jesusabdullah: call it callback-passing then |
| 01:46:35
| <Domenic_> | ricardobeat: no, the language is moving toward promises. existing APIs will be augmented or wrapped, just like Node's are today. |
| 01:47:57
| <Domenic_> | mbalho: what do you mean exactly. on top of indexeddb? |
| 01:49:33
| <mbalho> | Domenic_: yea |
| 01:49:59
| <mbalho> | Domenic_: i look at browsers like i look at node, js apis provided by native code, and always wonder what the decision making process is to add more native code |
| 01:50:11
| <Domenic_> | mbalho: i think that perspective on-list would be appreciated. they are under the impression all developers hate indexeddb and that people are doing development for chrome only because it has a nice fs api. (Actually, I think creationix is one of those people?) |
| 01:50:49
| <mbalho> | interesting |
| 01:51:22
| <mbalho> | so are they like 'since we cant fix indexeddb lets just make a new api that will be perfect but not address the failings of indexeddb' |
| 01:52:28
| <Domenic_> | well to some extent yeah, that's how the web has to work since you can't kill old APIs. but also something with a "file system" abstraction instead of a "database" abstraction. Not every developer can see that one can be built on top of the other, or wants to invest the effort in doing so. |
| 01:53:09
| <mbalho> | yea but it only takes 1 john resig and then nobody has to write against browser supplied apis :) |
| 01:53:11
| * calvinfo | quit (Quit: Leaving.) |
| 01:54:07
| * wolfeidau | quit (Remote host closed the connection) |
| 01:54:27
| <Domenic_> | i'm not sure that works for things with audiences as small as "file system access." |
| 01:54:59
| <mbalho> | well if the filesystem api intends on exposing actual file systems then i think its necessary, i wasnt aware of that goal |
| 01:55:00
| <Domenic_> | everyone knows, to do dom manip, use jQuery. It's going to be harder getting the message out that, to do fs access, use github.com/maxogden/fs |
| 01:55:22
| <mbalho> | people arent going to write webrtc themselves anymore because there are tons of competing abstractions |
| 01:55:37
| <mbalho> | i 100% dont believe that standards bodies should think that normal people will use their apis |
| 01:56:39
| <Domenic_> | hmm. well i guess that's where they (and I) disagree. they're hoping for a new era of not designing sucky stuff. |
| 01:56:50
| <mbalho> | if we had non crappy i/o then people would come up with good solutions for storing that i/o in the existing i/o storage mechanism (idb) |
| 01:57:07
| <mbalho> | i think standards bodies should focus on making things possible, not making things pretty |
| 01:57:16
| <mbalho> | i dont care how pretty something is |
| 01:57:51
| <Domenic_> | so, right, to some extent that is the philosophy. but (a) theory vs. practice, habits are hard to break; (b) the low-level stuff would be nicer if it were pretty, so they're trying. |
| 01:58:09
| <Domenic_> | also (c) browser game theory |
| 01:58:25
| <Domenic_> | i.e. if Chrome ships a FS API that people are using, Mozilla has to ship one or they lose developer marketshare. |
| 01:58:48
| <mbalho> | as long as there are no sacrifices made in terms of making things possible then i dont care how pretty they try to make it |
| 01:59:00
| <mbalho> | but i feel like a lot of time and effort is currently being taken up by pretty stuff |
| 01:59:43
| <mbalho> | e.g. you cant read idb in a web worker in firefix, you cant read a canvas as binary, you cant pause a file reader, you cant do openssl rsa encryption in the browser, etc |
| 01:59:57
| <Domenic_> | that's true |
| 02:00:04
| <Domenic_> | and that sucks |
| 02:00:09
| <mbalho> | but we hace a artisinally crafted backwards compatible future proof promises api that has been bikeshedded for thousands of man hours |
| 02:00:12
| <mbalho> | have* |
| 02:00:37
| <mbalho> | anyway, </rant> |
| 02:00:44
| <Domenic_> | i don't think enough people are communicating to them the specific failures like that |
| 02:01:33
| <mbalho> | its a representative democracy kind of thing, i dont have the time to sit through the bureacracy so i complain to you instead |
| 02:01:51
| <Domenic_> | all they have is vague stuff like "people hate indexeddb, we're not sure why. people are using chrome's fs, so we should probably prioritize that" |
| 02:02:29
| <Domenic_> | sure and that's totally valid. if you would take the time to write up a few sentences about each of those (why they're important, what use cases they block, etc.) I'd love to do my best to push for them to be fixed. |
| 02:02:38
| <mbalho> | cool |
| 02:04:41
| <Domenic_> | i've been pushing for real streams for a while based mainly on your presentation, and that seems to be getting *somewhere*... slowly. |
| 02:05:24
| <mbalho> | we should have public elections for commitees haha |
| 02:05:31
| <mbalho> | i would vote for the i/o part |
| 02:05:34
| <mbalho> | party* |
| 02:07:19
| <Domenic_> | haha |
| 02:07:52
| <Domenic_> | the thing is it's not like people are competing for these spots. it's really just whoever has the bandwidth to actually take the time and push through an API. |
| 02:08:19
| <mbalho> | ah yea |
| 02:08:30
| <mbalho> | we need to create competition :D |
| 02:08:31
| <Domenic_> | especially since whatwg, where all the real work happens these days, doesn't have the whole "member organizations" bs. anyone who writes a good spec and convinces implementers wins. |
| 02:09:32
| * mikeal | joined |
| 02:10:16
| * mikeal | quit (Client Quit) |
| 02:21:49
| * ricardobeat | quit (Ping timeout: 246 seconds) |
| 02:26:50
| * jxson | joined |
| 02:27:38
| * stagas | joined |
| 02:35:18
| * jxson | quit (Remote host closed the connection) |
| 02:36:53
| * jxson | joined |
| 02:36:56
| * jxson | quit (Remote host closed the connection) |
| 02:49:20
| * ricardobeat | joined |
| 02:54:35
| * gwenbell | joined |
| 03:03:50
| * gwenbell | quit (Ping timeout: 240 seconds) |
| 03:08:07
| * wolfeidau | joined |
| 03:08:25
| * wolfeidau | quit (Remote host closed the connection) |
| 03:09:59
| * mikeal | joined |
| 03:11:25
| * jergason | joined |
| 03:13:50
| * gwenbell | joined |
| 03:14:26
| * gwenbell | quit (Client Quit) |
| 03:20:33
| * wolfeidau | joined |
| 03:24:05
| * thlorenz | quit (Remote host closed the connection) |
| 03:27:42
| * ins0mnia | quit (Ping timeout: 264 seconds) |
| 03:28:15
| * calvinfo | joined |
| 03:33:02
| * calvinfo | quit (Client Quit) |
| 03:34:56
| * tmcw | joined |
| 03:34:59
| * tmcw | quit (Remote host closed the connection) |
| 03:46:43
| * mikeal | quit (Ping timeout: 264 seconds) |
| 03:48:18
| * stagas_ | joined |
| 03:48:37
| * timoxley | joined |
| 03:50:53
| * stagas | quit (Ping timeout: 256 seconds) |
| 03:51:08
| * stagas_ | changed nick to stagas |
| 03:54:15
| * timoxley | quit (Ping timeout: 260 seconds) |
| 04:01:00
| * wolfeidau | quit (Remote host closed the connection) |
| 04:12:16
| * mikeal | joined |
| 04:27:28
| * ralphtheninja | quit (Ping timeout: 264 seconds) |
| 04:28:25
| * timoxley | joined |
| 04:29:08
| * timoxley | quit (Remote host closed the connection) |
| 04:32:16
| * ricardobeat | quit (Ping timeout: 264 seconds) |
| 04:33:52
| * vitorpacheco | joined |
| 04:35:21
| * vitorpacheco | quit (Read error: Connection reset by peer) |
| 04:36:10
| * jergason | quit (Remote host closed the connection) |
| 04:38:51
| * jergason | joined |
| 04:38:55
| * jergason | quit (Remote host closed the connection) |
| 05:05:52
| * kumavis | joined |
| 05:12:37
| <dimadima> | was just reading through http://stackoverflow.com/questions/1606797/use-of-apply-with-new-operator-is-this-possible and bam! scrolled down and saw substack. <3 the internet |
| 05:15:13
| * chapel | joined |
| 05:20:53
| * kumavis | quit (Quit: kumavis) |
| 05:26:41
| <dimadima> | where's everyone else from the Internet idling? |
| 05:29:09
| <ik> | hi |
| 05:29:22
| * mikeal | quit (Read error: Connection reset by peer) |
| 05:31:16
| <dimadima> | hi ik |
| 05:31:20
| <ik> | hi |
| 05:31:38
| <ik> | It's late/early |
| 05:32:19
| <dimadima> | hah ya it is |
| 05:32:41
| <dimadima> | tiem is relative though |
| 05:34:01
| * mikeal | joined |
| 05:36:58
| * st_luke | joined |
| 05:37:30
| <ik> | relative to when i last slept |
| 05:54:22
| <dimadima> | :) |
| 05:54:54
| * mk30 | joined |
| 05:57:23
| * mk30_ | quit (Ping timeout: 250 seconds) |
| 06:00:19
| * st_luke | quit (Remote host closed the connection) |
| 06:00:31
| * AvianFlu | quit (Remote host closed the connection) |
| 06:00:58
| * AvianFlu | joined |
| 06:14:14
| * defunctzombie | changed nick to defunctzombie_zz |
| 07:01:10
| * mk30 | quit (Quit: Page closed) |
| 07:01:26
| * mk30 | joined |
| 07:15:53
| * defunctzombie_zz | changed nick to defunctzombie |
| 07:48:55
| * mikeal | quit (Quit: Leaving.) |
| 08:34:11
| * mikeal | joined |
| 08:37:30
| * mk30 | quit (Quit: Page closed) |
| 08:37:45
| * mk30 | joined |
| 08:42:29
| * jcrugzz | quit (Ping timeout: 264 seconds) |
| 08:49:24
| <substack> | isaacs: http://www.python.org/dev/peps/pep-0450/ |
| 08:49:32
| <substack> | never do this. |
| 09:08:03
| * mk30 | quit (Ping timeout: 250 seconds) |
| 09:34:03
| * jcrugzz | joined |
| 09:39:14
| * kesla | joined |
| 10:05:09
| * defunctzombie | changed nick to defunctzombie_zz |
| 10:29:30
| * kesla | quit (Ping timeout: 264 seconds) |
| 10:34:28
| * jibay | joined |
| 10:53:19
| * jcrugzz | quit (Quit: leaving) |
| 11:05:45
| * ralphtheninja | joined |
| 11:14:06
| * no9 | joined |
| 11:15:06
| * jibay | quit (Remote host closed the connection) |
| 11:49:17
| * yorick | joined |
| 12:00:22
| * ins0mnia | joined |
| 12:10:40
| * jibay | joined |
| 13:44:56
| * mikolalysenko | joined |
| 14:05:46
| * whit537 | quit (Quit: whit537) |
| 14:16:50
| * dominictarr | joined |
| 14:25:23
| * dominictarr | quit (Quit: dominictarr) |
| 14:37:47
| * jergason | joined |
| 14:39:06
| <jesusabdullah> | derf |
| 15:04:18
| * jergason | quit (Remote host closed the connection) |
| 15:07:03
| * dominictarr | joined |
| 15:34:47
| * jergason | joined |
| 15:59:42
| * jergason | quit (Ping timeout: 276 seconds) |
| 16:07:50
| * tmcw | joined |
| 16:10:17
| * tmcw | quit (Remote host closed the connection) |
| 16:13:07
| * mikolalysenko | quit (Ping timeout: 264 seconds) |
| 16:21:28
| * owen1 | quit (Ping timeout: 246 seconds) |
| 16:24:31
| * tmcw | joined |
| 16:28:23
| * mcollina | quit (Ping timeout: 260 seconds) |
| 16:30:53
| * mikolalysenko | joined |
| 16:39:25
| * tmcw | quit (Remote host closed the connection) |
| 16:48:35
| * mikeal | quit (Quit: Leaving.) |
| 17:02:52
| * tmcw | joined |
| 17:05:52
| <kanzure> | where is the http module defined here? https://github.com/alexgorbatchev/node-browser-builtins/blob/master/builtin/https.js |
| 17:11:57
| <kanzure> | oh.. https://github.com/substack/http-browserify |
| 17:12:04
| <kanzure> | cool |
| 17:17:05
| * kumavis | joined |
| 17:20:24
| * kumavis | quit (Client Quit) |
| 17:31:03
| * tmcw | quit (Remote host closed the connection) |
| 17:32:05
| * mikeal | joined |
| 17:33:17
| * jibay | quit (Read error: Operation timed out) |
| 17:34:47
| * kumavis | joined |
| 17:36:24
| * tmcw | joined |
| 17:43:59
| * mikeal | quit (Quit: Leaving.) |
| 17:47:35
| * jibay | joined |
| 17:48:56
| * AvianFlu | quit (Remote host closed the connection) |
| 17:49:36
| * tmcw | quit (Remote host closed the connection) |
| 17:50:05
| * AvianFlu | joined |
| 17:55:40
| * mikolalysenko | quit (Ping timeout: 264 seconds) |
| 17:57:29
| * tmcw | joined |
| 17:58:14
| * mikeal | joined |
| 18:01:47
| * mk30 | joined |
| 18:04:14
| * mikeal | quit (Quit: Leaving.) |
| 18:08:45
| * jibay | quit (Quit: Leaving) |
| 18:22:44
| * jergason | joined |
| 18:27:14
| * jergason | quit (Ping timeout: 264 seconds) |
| 18:30:54
| * tmcw | quit (Remote host closed the connection) |
| 18:33:43
| <dominictarr> | isaacs: question about compiled extensions: |
| 18:33:57
| <dominictarr> | do you need to recompile for every change in node version? |
| 18:34:03
| <dominictarr> | like updating a patch? |
| 18:34:42
| <dominictarr> | or will it become more stable? |
| 18:46:30
| * owen1 | joined |
| 18:47:25
| * mk30 | quit (Ping timeout: 250 seconds) |
| 18:54:23
| * defunctzombie_zz | changed nick to defunctzombie |
| 19:06:26
| <dominictarr> | THOUGHT: A service is better than a tool. |
| 19:06:31
| <dominictarr> | like, a CLI |
| 19:06:33
| <dominictarr> | too |
| 19:06:35
| <dominictarr> | tool |
| 19:06:52
| <dominictarr> | because a service is dynamic and always running |
| 19:07:21
| <dominictarr> | instead of having your workflow be a bunch of programs that you run |
| 19:07:47
| <dominictarr> | what would be way better, would if commands where messages that you sent to services |
| 19:08:27
| <dominictarr> | like, lets say you have a git service... |
| 19:08:36
| <dominictarr> | then you type git commit |
| 19:08:46
| <dominictarr> | and that is a message you are sending to that service. |
| 19:09:05
| <dominictarr> | which can then broardcast messages to other things that might care |
| 19:11:22
| <dominictarr> | or... |
| 19:11:46
| <dominictarr> | if npm was a service, rather than a program… then it becomes way cooler |
| 19:11:58
| <dominictarr> | firstly, it can manage your services for you |
| 19:12:03
| <dominictarr> | also, you can use it remotely |
| 19:12:10
| <dominictarr> | npm install X |
| 19:12:13
| <dominictarr> | to install X locally |
| 19:12:26
| <dlmanning> | CaaS |
| 19:12:33
| <dominictarr> | or npm --host myserver.com:9090 install X |
| 19:12:39
| <dominictarr> | to install X on that machine |
| 19:12:43
| <dominictarr> | dlmanning: C? |
| 19:12:47
| <dlmanning> | Clients |
| 19:13:41
| <dominictarr> | dlmanning: aha, right. |
| 19:13:55
| <dominictarr> | I've kinda stopped thinking of npm as a client |
| 19:14:01
| <dominictarr> | since working on npmd |
| 19:14:24
| <dominictarr> | like if npm is a service, it can pull down and keep it's cache uptodate |
| 19:14:46
| <dominictarr> | by connecting to the changes feed from the npm registry service |
| 19:20:25
| * calvinfo | joined |
| 19:21:53
| <isaacs> | dominictarr: you need to recompile for every unstable node version change. |
| 19:21:59
| <isaacs> | dominictarr: or if you switch between stable versions |
| 19:22:11
| <dominictarr> | isaacs: even patches? |
| 19:22:17
| <isaacs> | dominictarr: binary addons should not need to be recompiled going from, for example, 0.10.1 to 0.10.99 |
| 19:22:21
| <isaacs> | dominictarr: yes. |
| 19:22:29
| <isaacs> | dominictarr: unstable releases do not guarantee binary compatibility |
| 19:22:36
| <isaacs> | or API compatibility |
| 19:22:54
| <dominictarr> | right - so recompile when using unstable, but stable patches are okay |
| 19:22:59
| <isaacs> | dominictarr: eg, in the last 0.11 release, we completely changed the V8 API |
| 19:23:04
| <isaacs> | yes |
| 19:33:46
| * calvinfo | quit (Quit: Leaving.) |
| 19:35:21
| * jergason | joined |
| 19:53:50
| <dominictarr> | Raynos: continuable needs a function that turns a normal async callback style into a continuable |
| 19:54:28
| <dominictarr> | oh, I already implemented that |
| 20:26:10
| * mikeal | joined |
| 20:30:41
| * mikeal | quit (Client Quit) |
| 20:50:45
| * kumavis | quit (Quit: kumavis) |
| 20:51:42
| * jibay | joined |
| 20:54:52
| * Kessler | joined |
| 21:08:28
| <Kessler> | guys, maybe someone can tell me how do I deal with a problem like this: https://gist.github.com/kessler-y/6206812 (Recursive process.nextTick detected coming from a _stream_readable) any help would be vastly appreciated :) |
| 21:10:01
| <Kessler> | even hints or general direction pointing fingers .... |
| 21:19:39
| * kumavis | joined |
| 21:25:30
| * evbogue | joined |
| 21:34:29
| * wolfeidau | joined |
| 21:51:41
| * wolfeidau | quit (Remote host closed the connection) |
| 21:52:20
| * stagas | quit (Ping timeout: 240 seconds) |
| 22:16:59
| * Kessler | quit (Ping timeout: 260 seconds) |
| 22:30:46
| * kumavis | quit (Quit: kumavis) |
| 23:08:12
| * st_luke | joined |
| 23:15:24
| * jergason | quit (Remote host closed the connection) |
| 23:15:33
| * jcrugzz | joined |
| 23:18:47
| * damonoehlman | joined |
| 23:19:31
| * mikeal | joined |
| 23:33:58
| * dominictarr | quit (Quit: dominictarr) |
| 23:55:16
| * thlorenz | joined |
| 23:59:42
| * kumavis | joined |