00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:02:50  <jcrugzz>wolfeidau: rvagg has kindly told me you may be working on a node based graphite using levelup. I would love to know more :D.
00:04:05  <wolfeidau>jcrugzz: haha yeah i was messing around with collectd and node trying to do something like graphites whisper files or RRD files do
00:04:52  <wolfeidau>This was using map-reduce https://github.com/dominictarr/map-reduce issue i had was how it worked internally
00:05:16  <wolfeidau>jcrugzz: The core issue is mainting a rolling data set inside leveldb is hard at the moment
00:06:08  <jcrugzz>wolfeidau: is this because of how leveldb behaves in general?
00:06:30  <rvagg>it's because wolfeidau hasn't written an extension to do a more suitable map-reduce
00:06:59  <wolfeidau>jcrugzz: No leveldb is awesome, the issue which i am sure has been solved in redis and others is just storing time series data with average, min, max, median
00:07:10  <wolfeidau>^
00:07:44  <wolfeidau>jcrugzz: It isn't a complicated problem and i have found a few small pieces of the puzzle jsut haven't built it yet :)
00:08:41  <jcrugzz>wolfeidau: ahh ok, well i would love to help out where I can :D.
00:09:56  <jcrugzz>havent allocated the time to mess with leveldb too much yet having been busy working on @nodejitsu internals but i am always interested in learning
00:10:15  <jcrugzz>and id love to incorporate it into our monitoring system
00:10:41  <wolfeidau>jcrugzz: This is what i was hacking on https://github.com/wolfeidau/datum the core issue is i need a k,v which i can stream metrics into and have the stream roll them over like carbon service does
00:11:01  <rvagg>its super simple jcrugzz, see the last dailyjs post about it; the complicated bit is piecing together the bits on top of it to do what you want--many of the pieces exist but you'll likely have to tinker with building your own if you have complicated needs
00:11:36  <wolfeidau>jcrugzz: https://github.com/wolfeidau/datum/blob/master/lib/bucket_calculator.js this is the bit of code which I will probably break out into a module it calculates averages on a stream
00:11:39  <rvagg>wolfeidau: datum! that's it, I mentioned your work with statsd+levelup the other night at Node.ninjas and someone was asking for the project name but I couldn't for the life of me remember off the top of my head
00:12:21  <jcrugzz>rvagg: yea i have that chilling in my pocket queue, gonna dig into it this weekend
00:12:23  <wolfeidau>rvagg: Yeah i am on a bit of a sebatical currently using graphite which has been mindblowing so far
00:12:39  * tmcwjoined
00:13:08  <jcrugzz>wolfeidau: we currently are using https://github.com/indexzero/window-stream
00:13:37  <jcrugzz>to do those type of calculations with the system we are doing based on https://github.com/nodejitsu/godot
00:13:43  <wolfeidau>jcrugzz: Yeah i found a couple like it but needed to write one calc myself :)
00:13:51  <wolfeidau>So i could understand how they worked
00:14:00  <jcrugzz>yea makes sense :)
00:14:12  <wolfeidau>That one looks much better better
00:15:21  <wolfeidau>jcrugzz: So really the missing piece is that storage mechanism, my project should run tests fine, if you use lev to dump the db and sniff around you will get a feel for how simple levelup is
00:15:40  <wolfeidau>jcrugzz: https://github.com/hij1nx/lev
00:16:23  <wolfeidau>jcrugzz: I am happy to hack on it more I just need to get over that small problem
00:17:11  <jcrugzz>wolfeidau: ok cool, will do some digging this weekend. I will be in conctact :)
00:19:03  <wolfeidau>jcrugzz: No problem mate I am always around and in here or rvagg knows where i am :)
00:19:15  <jcrugzz>rvagg: thank you for facilitating the introduction
00:19:28  <wolfeidau>jcrugzz: @wolfeidau on twitter as well
00:20:00  <jcrugzz>wolfeidau: you can find me @jcrugzz on twitter also
00:20:59  <rvagg>facilitating introductions seems to be one of my core skills
00:32:50  * tmcwquit (Remote host closed the connection)
00:33:48  <Raynos>great sockjs / shoe no longer does websockets in 0.10 :/
00:38:55  * mcollinajoined
00:44:07  * mcollinaquit (Ping timeout: 276 seconds)
00:46:26  * timoxleyquit (Quit: Textual IRC Client: www.textualapp.com)
00:47:22  * timoxleyjoined
00:47:26  <ralphtheninja>rvagg: nice example with the variance and read stream!
00:47:39  <ralphtheninja>always good to have a 'real' example
00:54:41  <jesusabdullah>if I can be real, I've never been able to get shoe to work properly even in 0.8
00:54:53  <jesusabdullah>for some reason even straight following the examples it gets angry at me :C
01:01:39  <jjjjohnn1y>hyperquest, hyperscript, hyperuppercut
01:08:24  * heathjsjoined
01:08:43  * creationixquit (Ping timeout: 245 seconds)
01:08:43  * heathquit (Read error: Connection reset by peer)
01:10:24  * mikolalysenkoquit (Ping timeout: 264 seconds)
01:10:50  * creationixjoined
01:11:19  * ralphtheninjaquit (Ping timeout: 264 seconds)
01:13:09  * elliottc1blejoined
01:13:20  * elliottcable_quit (*.net *.split)
01:13:20  * elliottcablequit (*.net *.split)
01:13:20  * rvaggquit (*.net *.split)
01:13:20  * Domenic_quit (*.net *.split)
01:13:20  * rook2pawnquit (*.net *.split)
01:14:08  * Domenic_joined
01:15:26  * jolissjoined
01:15:28  * rook2pawnjoined
01:15:36  * elliottcable_joined
01:17:28  * ralphtheninjajoined
01:20:06  * jcrugzzquit (Ping timeout: 256 seconds)
01:22:05  * nicholasfjoined
01:22:50  * rvaggjoined
01:27:33  * tim_smart|awayquit (Ping timeout: 245 seconds)
01:29:58  * tim_smart|awayjoined
01:29:59  * tim_smart|awaychanged nick to tim_smart
01:32:57  * creationixquit (Ping timeout: 245 seconds)
01:32:57  * Raltquit (Ping timeout: 245 seconds)
01:34:01  * johnkpaulquit (Ping timeout: 245 seconds)
01:34:01  * _ddgbotquit (Ping timeout: 245 seconds)
01:34:21  * tim_smartquit (Ping timeout: 245 seconds)
01:34:54  * juliangruber_joined
01:35:22  * nicholasfquit (Read error: Connection reset by peer)
01:35:45  * joliss_joined
01:35:58  * tim_smart|awayjoined
01:36:01  * nicholasfjoined
01:36:02  * tim_smart|awaychanged nick to tim_smart
01:37:07  * creationixjoined
01:37:18  * Ralt_joined
01:37:35  * rvaggquit (Ping timeout: 245 seconds)
01:37:35  * elliottc1blequit (Ping timeout: 245 seconds)
01:37:35  * heathjsquit (Ping timeout: 245 seconds)
01:37:35  * juliangruberquit (Ping timeout: 245 seconds)
01:37:36  * Ralt_changed nick to Ralt
01:37:40  * heathjoined
01:37:40  * heathquit (Changing host)
01:37:40  * heathjoined
01:38:17  * dools_joined
01:39:02  * simcop2387_joined
01:39:03  * dfgg_joined
01:39:25  * jjjjohnnnyjoined
01:39:32  * rook2paw1joined
01:39:32  * johnkpauljoined
01:40:32  * CoverSli1ejoined
01:40:36  * rvaggjoined
01:41:01  * jolissquit (Ping timeout: 268 seconds)
01:41:01  * joliss_changed nick to joliss
01:41:02  * elliottcable_quit (Ping timeout: 268 seconds)
01:41:02  * CoverSlidequit (Ping timeout: 268 seconds)
01:41:03  * rook2pawnquit (Ping timeout: 268 seconds)
01:41:03  * jjjjohnn1yquit (Ping timeout: 268 seconds)
01:41:08  * ryanseddonquit (Ping timeout: 268 seconds)
01:41:08  * pikpikquit (Ping timeout: 268 seconds)
01:41:59  * elliottcable_joined
01:42:14  * elliottcablejoined
01:44:12  * ircretaryquit (*.net *.split)
01:44:13  * kanzurequit (*.net *.split)
01:44:13  * simcop2387quit (*.net *.split)
01:44:13  * dfggquit (*.net *.split)
01:44:13  * doolsquit (*.net *.split)
01:44:15  * simcop2387_changed nick to simcop2387
01:56:46  * rvaggquit (*.net *.split)
01:57:06  * rvagg_joined
01:57:16  * mint_xianchanged nick to 20WACB5BM
01:57:17  * rvagg_changed nick to rvagg
01:57:26  * mint_xianjoined
01:57:26  * rvaggquit (Client Quit)
01:58:44  * rvaggjoined
01:58:44  * elliottcable_quit (Ping timeout: 245 seconds)
01:59:13  * elliottcable_joined
01:59:44  * jesusabd1llahjoined
02:00:32  * simcop2387_joined
02:01:17  * saijanai_quit (Ping timeout: 252 seconds)
02:03:02  * simcop2387quit (*.net *.split)
02:03:02  * 20WACB5BMquit (*.net *.split)
02:03:03  * munroquit (*.net *.split)
02:03:03  * occamshatchetquit (*.net *.split)
02:03:03  * jesusabdullahquit (*.net *.split)
02:03:03  * FireFlyquit (*.net *.split)
02:03:03  * simcop2387_changed nick to simcop2387
02:04:54  * munrojoined
02:05:44  * FireFlyjoined
02:07:19  * isaacsquit (Ping timeout: 252 seconds)
02:07:20  * jan____quit (Ping timeout: 252 seconds)
02:07:20  * jlordquit (Ping timeout: 252 seconds)
02:07:32  * jlordjoined
02:09:36  * dfgg_quit (Ping timeout: 245 seconds)
02:10:04  * isaacsjoined
02:10:28  * isaacschanged nick to Guest85717
02:10:49  * jan____joined
02:11:01  * CoverSli1equit (*.net *.split)
02:11:01  * creationixquit (*.net *.split)
02:11:01  * nicholasfquit (*.net *.split)
02:11:01  * ralphtheninjaquit (*.net *.split)
02:11:01  * timoxleyquit (*.net *.split)
02:15:28  * dfggjoined
02:15:42  * CoverSli1ejoined
02:15:42  * creationixjoined
02:15:42  * nicholasfjoined
02:15:42  * timoxleyjoined
02:19:44  * jan____-joined
02:19:45  * munroquit (*.net *.split)
02:19:45  * FireFlyquit (*.net *.split)
02:19:45  * elliottcable_quit (*.net *.split)
02:20:00  * elliottcable_joined
02:20:40  * jan____quit (Ping timeout: 276 seconds)
02:21:11  * jan____-changed nick to jan____
02:21:21  * Effilryjoined
02:23:16  * jlord_joined
02:23:41  * ralphtheninjajoined
02:26:10  * jlordquit (*.net *.split)
02:29:22  * elliottcable_quit (Ping timeout: 268 seconds)
02:29:22  * elliottcablequit (Ping timeout: 268 seconds)
02:29:39  * elliottcablejoined
02:30:00  * elliottcable_joined
02:31:08  * ralphtheninjaquit (Ping timeout: 252 seconds)
02:38:24  * elliottcable__joined
02:42:56  * dfgg_joined
02:44:14  * elliottcable_quit (Ping timeout: 268 seconds)
02:44:18  * rvaggquit (Ping timeout: 268 seconds)
02:44:18  * dfggquit (Ping timeout: 268 seconds)
02:44:59  * rvaggjoined
02:45:27  * elliottcable__changed nick to elliottcable_
02:52:49  * rvaggquit (Ping timeout: 252 seconds)
02:52:50  * dfgg_quit (Ping timeout: 252 seconds)
02:52:56  * dfggjoined
02:53:00  * joliss_joined
02:53:16  * Effilryquit (*.net *.split)
02:53:16  * Guest85717quit (*.net *.split)
02:53:17  * jesusabd1llahquit (*.net *.split)
02:53:17  * jolissquit (*.net *.split)
02:53:26  * joliss_changed nick to joliss
02:55:20  * Effilryjoined
02:55:59  * rvaggjoined
02:57:53  * isaacs_joined
02:58:17  * isaacs_changed nick to Guest81397
02:59:23  * jesusabdullahjoined
03:08:07  * simcop2387_joined
03:08:08  * simcop2387_quit (Changing host)
03:08:08  * simcop2387_joined
03:11:01  * simcop2387quit (*.net *.split)
03:11:01  * simcop2387_changed nick to simcop2387
03:26:29  * timoxleyquit (Quit: Computer has gone to sleep.)
03:37:44  * ryanseddonjoined
03:37:56  * pikpikjoined
03:45:36  * blobaumjoined
04:06:56  * timoxleyjoined
04:13:46  * munrojoined
04:41:44  * mikolalysenkojoined
04:43:24  * fotoveritejoined
04:47:32  * st_lukejoined
04:58:14  <hij1nx>wolfeidau: i'd like to replace graphite with levelweb plugins, the browserify rewrite of levelweb makes it (more) possible to create and add visualizations but there is more to be done so that it is plug-and-play-ish
04:59:36  * timoxleyquit (Ping timeout: 245 seconds)
05:34:32  <wolfeidau>hij1nx: cool yeah tbh i don't have a big issue with graphite, it is just the system as a whole is a pig to setup and currently i use 1% of it
05:35:19  <wolfeidau>hij1nx: Also a KV is a great for fit
05:40:56  * jcrugzzjoined
05:46:23  * dguttmanquit (Quit: dguttman)
05:46:55  * nicholasfquit (Read error: Connection reset by peer)
05:47:20  * nicholasfjoined
05:48:48  * dguttmanjoined
05:51:12  * jcrugzz_joined
05:53:18  * jcrugzzquit (Ping timeout: 272 seconds)
06:05:24  * stagasjoined
06:07:07  * mikolalysenkoquit (Ping timeout: 256 seconds)
06:09:42  * st_lukequit (Remote host closed the connection)
06:24:06  * timoxleyjoined
06:33:29  * nicholasfquit (Remote host closed the connection)
06:43:15  * wolfeidauquit (Remote host closed the connection)
06:43:52  * wolfeidaujoined
06:57:33  * jcrugzz_quit (Ping timeout: 256 seconds)
07:31:24  * dominictarrjoined
07:31:46  <jden>dominictarr: hey there
07:32:23  <rvagg>dominictarr: talk well received?
07:32:32  <dominictarr>jden: hey, whats up?
07:32:32  <dominictarr>yes!
07:33:11  <jden>dominictarr: you seem like you would know this: in node, can I change the shell CWD? eg, could I implement cd.js like bash `cd`?
07:34:11  <rvagg>jden: process.chdir()
07:34:16  <chapel>dominictarr: what was your talk?
07:34:20  <rvagg>then inspect with process.cwd()
07:34:40  <rvagg>dominictarr: have you got your content/slides online somewhere? I like the sound of the structure of it from this writeup: http://decadecity.net/blog/2013/05/10/dominic-tarr-database-future-leveldb
07:34:46  <jden>rvagg: ahh, thanks :)
07:36:51  <jden>I spent today at at mongodb conference in San Francisco
07:37:13  <jden>and came away with the distinct impression that I needed a modular DB system :)
07:37:18  <jden>eg not mongo
07:37:21  <dominictarr>chapel: yeah, I'll put it on github soon
07:37:32  <chapel>dominictarr: awesome, reading the notes rvagg linked
07:37:39  * chapelis moving to the bay area
07:37:51  <chapel>I got a job down there
07:38:05  <jden>oh yeah? where / what?
07:38:13  <chapel>walmart labs
07:38:21  <rvagg>I gave a similar talk to a small node noob audience on Thursday night and the response was amazing, unexpected but it seems like people really are keen for a rethink on this whole 'database' thing
07:38:23  <jden>ah, right on. evil empire, etc etc
07:38:27  <chapel>yep for sure
07:38:41  <chapel>my gf used to work at walmart (on the floor) lol
07:38:54  <rvagg>chapel: congrats! working with Eran and the rest? that'd be a lot of fun I reckon
07:38:57  <jden>if it gets overbearing, you can always come chill with us at agile :)
07:39:08  <chapel>sadly not with Eran, they are a separate group
07:39:25  <rvagg>ahh, you'll be working on Node stuff though?
07:39:45  <chapel>will be working on a small team built from some of the core guys from Kosmix (who walmart purchased and created walmart labs with)
07:39:54  <jden>rvagg, chapel, have you seen the incredible artwork from Eran's recent node enterprise talk
07:39:55  <chapel>and yeah, mostly node
07:39:57  <jden>?
07:40:04  <rvagg>jden: yeah! that's a great talk too
07:40:12  <chapel>jden: I didn't see it, but I did hear about it, slides anywhere?
07:40:29  <dominictarr>rvagg: I called old databases (with non tailable queries) "Vorgon Optimized"
07:41:01  <rvagg>heh
07:41:30  <jden>chapel: they're somehwere on the internet :) I'd check @hueniverse's twitter history
07:41:43  <chapel>yeah, will do
07:41:50  <rvagg>dominictarr: my pitch was that when you buy into an existing monolithic database you end up designing your app around the structure that the database rather than having your database as a slave to your app
07:41:53  <jden>dominictarr: sounds about right
07:42:02  <rvagg>chapel: http://joyent.com/company/events/node-meetup-april-2013
07:42:06  <rvagg>bottom video
07:42:18  <rvagg>Ranney's talk is interesting too
07:42:32  <dominictarr>rvagg: yes, the database should change to fit your data,
07:42:34  <chapel>rvagg: I agree about that, though, even with level you do model your data around how it works, but you have a lot more control
07:42:40  <dominictarr>not your data should change to fit the database.
07:42:43  <jden>yep. I was there for that meetup. it was good stuff. izs seemed tired though
07:42:58  <chapel>its not as drastic as other databases, and is infinitely more flexible
07:43:03  <rvagg>dominictarr: yeah, and when I started listing off existing extensions and the crazy ways they extend the core functionality I think it started to click how flexible this ecosystem could be
07:43:31  <rvagg>chapel: not necessarily, have you looked at https://github.com/mcollina/node-levelgraph/ ?
07:43:36  * jaz303joined
07:43:54  <rvagg>it's just a 2D storage space but so are the backends to most (all) existing databases, bend it to your will!
07:44:13  <jden>dominictarr, rvagg: curious, do you guys have thoughts on datomic?
07:44:22  <chapel>rvagg: for sure, you are right in the case of being able to model the data how you want in general
07:44:28  <jden>spent some time this week studying it
07:44:31  <dominictarr>jden: I've read the docs
07:44:44  <chapel>but you have to design around its inherent features or lack there of (which is more a boon than anything)
07:45:07  <rvagg>jden: my thoughts are this: I appreciate the immutable view of data that hickey promotes but the biggest win of datomic is bringing the database in to the core of your application
07:45:10  <dominictarr>the central transactor with processing dbs isn't too uncommon an idea
07:46:07  <jden>unique !== uncommon :) remember, I still mostly inhabit a stratum of plebeian developers, not super awesome heady academic developers
07:46:09  <dominictarr>and the appending timestamp data is just like couch db - btrees
07:46:55  <dominictarr>jden: I mean, there are other databases that have that, or can be configured to do that
07:47:17  <dominictarr>oh, like, using master-slave replication with mongo will give you that=
07:47:19  <dominictarr>!
07:47:33  <jden>rvagg: db-in-app is great. it's something I've been doing for a while, although often against the grain, or with something like memcached or redis for essentially offline mirrored transaction processing
07:47:37  <chapel>question for rvagg and dominictarr, would it be acceptable to build something on levelup but not as a module of it perse
07:47:40  <jden>s/transaction/query/
07:48:33  <chapel>since you two seem to be the main proponents of leveldb in general
07:48:39  <jden>dominictarr: yeah, the inherently (or at least, default) append-only nature is actually a really good fit for my domain (healthcare) wrt audit logging
07:48:41  <dominictarr>jden: the more interesting feature is being able to "checkout" any old snapshot of the data
07:49:04  <rvagg>chapel: there's a bunch of them already, just using it as a binding layer, that's all it was originally meant to be so that's cool, http://npm.im/level1 for example
07:49:11  <dominictarr>yeah, if auditability is important to you
07:49:17  <dominictarr>that could be invaluable!
07:49:19  <jden>yes. a frequent requirement is to be able to answer the question "who has access to what when, and why?"
07:50:30  <dominictarr>rvagg: how would you build that in level-?
07:50:42  <dominictarr>could you just append a timestamp to every key
07:50:45  <jden>for the record, american healthcare privacy/security regulations are totally screwed up. on the one hand, you need strict privacy policy. on the other, you need perfect auditing. a side effect is that the audit logs themselved become privacy-sensitive information.
07:51:07  <dominictarr>and then do a get as a limit 1 reverse range?
07:51:25  <dominictarr>jden: haha, right
07:51:31  <rvagg>dominictarr: yeah, I've talked to a few people that are keen to have a temporal aspect to data, I think it'd probably need a timestamped version for each write with a pointer entry to make it easy to get the current version (or a reverse readStream would probably suffice I suppose)
07:51:48  <jden>dominictarr: and of course, access to the audit logs is auditable :)
07:52:10  <dominictarr>jden: retriving the audit log is logged?
07:52:24  <jden>yep.
07:52:48  <dominictarr>jden: maybe you could have a cryptographic audit log
07:53:03  <jden>any time you introduce less than perfect trust into a system, you end up with huge overhead.
07:53:12  <dominictarr>where each record includes a hash of the previous value, like in couch or git
07:53:50  <jden>basically, the audit logs need to be immutable and self-logging
07:53:54  <dominictarr>jden: that is very well put.
07:54:02  <dominictarr>it's like that in real life too...
07:54:03  <jden>goedell might have something to say about this
07:55:25  <dominictarr>jden: I use something like an audit log for master-slave replication
07:55:46  <dominictarr>basically, turn each put into a batch that also saves a log
07:56:50  <jden>what do you mean by batch?
07:57:20  <dominictarr>a batch atomically puts/deletes several things
07:57:32  <dominictarr>so, it either fails or succeeds
07:57:35  <jden>like a transaction?
07:57:40  <dominictarr>but never partially succeeds
07:57:52  <dominictarr>you could use it to implement transactions
07:57:57  <dominictarr>it doesn't do locking
07:58:12  <jden>is locking an essential feature of transactions?
07:58:15  <chapel>doesn't lock, and is only put and/or delete
07:58:46  <dominictarr>jden: well, it depends on what you mean by a transaction...
07:59:05  <jden>well, I guess I'm not operating form a formal definition - just my experience
07:59:23  <jden>which, if you had asked me to expalin a transaction 10 minutes ago, I would have given the definition you just did
07:59:31  <dominictarr>right
07:59:45  <dominictarr>so, a batch is kinda like a simple transaction
07:59:55  <jden>and I probably would have used the phrase "roll back" :)
08:00:09  <dominictarr>right - there is no rollback in this one
08:00:35  <jden>so there's no partial success, but a failure can have side effects?
08:01:03  <rvagg>if there's a crash then the db should be automatically repaired when it's opened again
08:01:14  <dominictarr>yeah
08:01:28  <jden>rvagg: what if it's not a crash, but a validation error or something similar?
08:01:49  <chapel>jden: essentially, if it didn't finish, the whole batch is discarded
08:01:50  <dominictarr>leveldb doesn't have built in validation errors
08:01:58  <jden>eg, there's no failure of availability, but just with a given command? in http terms, a 400 rather than a 500
08:02:07  <rvagg>jden: leveldb is a super simple storage mechanism, we have a single-thread JS gatekeeper where we can deal with validation and whatnot if need be
08:02:37  <rvagg>i.e. there's no pure notion of transactions but it's not out of the question in Node on top of leveldb
08:02:40  <chapel>jden: leveldb wouldn't crash, if your process crashed during a transaction
08:02:41  <jden>ah - I guess I'm talking about data systems in general rather than leveldb in particular
08:02:58  <jden>trying to understand the term batch
08:03:00  <chapel>the transaction would be ignored if it didn't finish
08:03:16  <jden>chapel: in a 2 phase commit fashion?
08:03:29  <chapel>no
08:03:40  <chapel>I don't know the particulars, but I assume its part of the log writing
08:03:45  <dominictarr>jden: so, there is a in memory db, that has the recently added records
08:03:51  <dominictarr>which is backed with a log
08:03:51  <chapel>where as, if a batch write to log doesn't finish, the whole batch is ignored
08:03:54  <rvagg>I've personally never had a whole lot of need for true transactions in the systems I've been involved in building, reliance on transactions may indicate that you're relying too much on database features that could be done in your app
08:04:42  <chapel>rvagg: the nice thing about transactions is being able to do multiple writes that are required
08:04:52  <jden>rvagg: it's a bubble-wrap problem. if you're lucky enough to have a domain (or disciplined enough in modelling the domain) to avoid the issue, then you gain in simplicity
08:04:57  <rvagg>chapel: yeah, so if that's all you need, queue & batch()
08:04:58  <chapel>it ensures that if the write doesn't finish, you don't have incomplete data
08:05:35  <chapel>for instance, Im working on indexes, it makes it easy to write all the indexes when the main value is being written
08:05:55  <dominictarr>chapel: you can do that with batches
08:05:58  <rvagg>chapel: yeah, so dominictarr's level-hooks stuff does that
08:06:08  <chapel>dominictarr: I know, thats what Im saying
08:06:11  <dominictarr>right
08:06:19  <chapel>I use batches directly
08:06:27  <chapel>very easy :)
08:06:40  <rvagg>right, so we're all in agreement, transactions are for sissies, I'll make an announcement
08:06:42  <chapel>though the lower level binding would be better
08:06:46  <jden>I'm afraid I still don;t have a very good handle on this
08:06:54  <chapel>I guess I was meaning batches when saying transactions
08:06:55  <jden>is there anything I can read on this?
08:07:06  <chapel>sorry for confusing anyone
08:07:16  <rvagg>jden: http://dailyjs.com/2013/05/03/leveldb-and-node-2/ has a ton of levelup-specific stuff
08:07:17  <jden>if not, I'm happy to continue asking clarifying questions
08:07:22  <rvagg>jden: first article has leveldb-specific stuff
08:07:36  <dominictarr>jden: go ahead
08:08:02  <jden>so, you all have metnioned a "log" several times
08:08:11  <jden>is this akin to journaling?
08:08:19  <jden>ie, a persistence queue?
08:08:30  <chapel>jden: leveldb uses an append log for initial writes
08:08:41  <rvagg>http://dailyjs.com/2013/04/19/leveldb-and-node-1/ has stuff about the log & what the levels are
08:08:47  <chapel>which are then compiled into different storage systems depending on the age and size
08:09:01  <chapel>yes, rvagg's article is good
08:09:19  <jden>rvagg: thanks for the links, I'll be sure to read them - but for the sake of this conversation, I'll read them async :)
08:09:29  <rvagg>heh
08:09:31  <jden>does the log offer durability guaratees?
08:09:41  <rvagg>yes, if it makes it into the log then all's good
08:09:45  <chapel>jden: it is append only
08:09:54  <rvagg>write to leveldb and it gets stuck in the log straight up and in a 'memtable' for quick access
08:09:58  <chapel>so any partial writes are ignored (in case of a crash)
08:10:01  <rvagg>it's perioically flushed into sorted table files
08:10:24  <jden>so it seems like there are 2 major cases from a data integrity perspective
08:10:32  <jden>1 involving crashes and system failures
08:10:40  <jden>which is important, but the exceptional case
08:10:51  <rvagg>normal leveldb writes aren't done fsync but you can force that if the data is important enough (db.put('foo', 'bar', { sync: true }, cb))
08:11:01  <jden>and another, involving complex operations, which mutate many pieces of data at once
08:11:34  <rvagg>yeah, so a common case that you'
08:11:37  <jden>is this second case pushed to an application level concern?
08:12:03  <rvagg>that you'll find in dominic's code (hooks & sublevel etc.) is taking a standard put() and doing something with it that generates extra data and sending it down to leveldb as a batch() of multiple writes
08:12:47  <jden>is it fair to say that a transaction can be implemented over a batch with the addition of memento objects to add rollback/undo?
08:13:17  <rvagg>I think the case we're trying to make is that most of this stuff is almost everything but the basic read & write operations are an application level concern, the core is small, the extensions add fancy stuff as required
08:13:34  <rvagg>jden: yeah, that'd be a neat way to do it actually
08:14:02  <rvagg>rewrite put() to add the extra meta stuff with a batch(), use dominictarr's level-sublevel to partition the namespaces cleanly so it doesn't get messy
08:14:23  <jden>rvagg: totally. I buy minimizing cores, separation of concerns, modular data systems, etc. but I want composable primitives, so I can choose data patterns that are maximally minimal, but not more minimal than is necessary/useful for a particular application
08:14:51  <chapel>rvagg: I really think you all should push for binary (buffer) keys
08:14:57  <rvagg>right, so you build your primitives at the lowest level of extensions
08:15:02  <jden>yes
08:15:11  <chapel>not necessarily on the user level
08:15:35  <dominictarr>jden: yes, complex transactions is application level
08:15:39  <jden>from a threat/audit modelling point of view, you are almost forced to think in tiers
08:16:17  <jden>in american healthcare software
08:17:16  <chapel>jden: the funny thing, I spent the last 2+ weeks reading/researching leveldb and all the various modules related to it
08:17:33  <chapel>jden: where normally I'd just jump in and write code
08:18:18  <chapel>but due to the different way of thinking, or really the freedom of application, I felt the need to research to know where to focus and move forward
08:21:50  <jden>chapel: what usecases are you looking at for it?
08:22:14  <chapel>well, I came from using mongo primarily, with mongoose in front
08:22:24  <jden>tangential question: can leveldb truly be called a db? or is it just a storage component which can be used to create a data system?
08:22:33  <chapel>I enjoy some of the built in functionality, like easy indexing
08:23:04  <jden>maybe my bias is systems thnking - but even coming from a mongodb world at work, I've started to think of it as just one piece of a larger system
08:23:19  <chapel>but essentially, I like the idea of having the data closer to the application, because I can do more with it, and not have to manage another server (the database)
08:23:51  <jden>in minimal trust environments like mine, centralization of data access is actually quite attractive
08:24:18  <rvagg>jden: I call it a 'data store' generally, a database is what we build on top of it
08:24:18  <jden>there are techniques to push the data to the edge, and they mostly rely on crypto, and they're are for the sake of latency reduction
08:24:46  <jden>rvagg: cool - that's consistent with what I'm thinking of
08:24:57  <jden>I've had the "KVS-isnt-a-db
08:25:03  <jden> " conversation lately
08:25:28  <rvagg>yeah, I'm kind of sympathetic to that view, but I'm not sure how much the terminology matters
08:26:04  <chapel>jden: the great thing about having it inside your application, is because it is easy to expand and augment how you handle the data, because you use or build as much as you need, the features you want
08:26:12  <jden>rvagg: only insofar as it influences the way you think about it. eg earlier we were talking about how the database has a big influence in how you model data
08:26:20  <rvagg>it's just a piece of the puzzle, not the main attraction, these beasts (oracle, mysql, postgresql, mongo, riak, etc. etc.) like to make themselves a core part of the show
08:26:24  <chapel>not a bunch of stuff that doesn't matter or has a negative effect
08:26:36  <jden>if you break it down into a storage component vs the other functionality you need, eg indexing, querying, etc, then you might build systems differently
08:26:39  <jden>this effect matters
08:27:08  <chapel>jden: leveldb reminds me of node a lot when I first got into it
08:27:16  <chapel>in that, node is low level
08:27:20  <chapel>by itself it doesn't do anything
08:27:46  <chapel>you build an application with node, but before that you have to build a server or something to handle the application functionality
08:27:54  <rvagg>aye, I think that's the core value we're trying to take forward
08:28:33  <chapel>with leveldb, it is just a datastore as rvagg said, and with levelup and modules, you can build a database or any functionality you need on top of it
08:28:41  <jden>that's cool. It's a lot of mental overhead in terms of mass market adoption.
08:28:53  <jden>but maybe there will be an equivalent to express that emerges on top of leveld
08:28:58  <jden>leveldb*
08:28:59  <chapel>jden: node itself is continuing to grow
08:29:30  <rvagg>so, one of the things I tell people is--we've come from a place of being subservient to "the web server", monoliths like Apache, IIS, etc. and we built our applications around them.. in Node and other modern platforms we've told them to get lost and we *build our own webserver* which would be a crazy notion just 10 years ago
08:29:43  <rvagg>so.. why not *build your own database*, sounds crazy now, but perhaps it won't in time
08:29:49  <chapel>rvagg: exactly
08:30:05  <chapel>has anyone done speed tests in comparison to lets say redis
08:30:06  <jden>absolutely. it's a very nice place to be. I spend most of my daily energy in higher-level application domains, but I really like being able to peal back the layers of abstraction down to the tcp level in node, for example
08:30:07  <dominictarr>jden: https://gist.github.com/dominictarr/5559302
08:30:12  <chapel>I know redis is faster due to memory and all
08:30:21  <chapel>but how much faster
08:30:29  <rvagg>chapel: these are the most recent, https://gist.github.com/juliangruber/5139252
08:30:35  <dominictarr>that basically how i'd do thte things it sounds like you want, using current modules
08:30:38  * Effilrychanged nick to FireFly
08:30:39  <rvagg>tho I can't vouch for them, blame juliangruber_
08:31:13  <rvagg>(to my eye, the difference between levelup & leveldown is a bit too suspicious)
08:31:48  <jden>dominictarr: didn't I see a module for implementing the same leveldb interface on top of indexedb or something (and yes, I appreciate the redundancy :) )
08:31:59  <chapel>rvagg: my thought process is that, instead of using redis as longer term (longer than the process) memory, why not use leveldb since it has less overhead
08:31:59  <dominictarr>jden: level.js
08:32:05  <rvagg>jden maxogden/level.js
08:32:07  <juliangruber_>rvagg chapel: those are the most up2date tests: https://github.com/juliangruber/multilevel-bench
08:32:12  <chapel>if that link is to be believed, leveldb performs very well
08:32:38  <dominictarr>rvagg: I think there are some more recent benchmarks than that
08:32:54  <juliangruber_>chapel: you can see all the code in the multilevel-bench repo
08:33:02  * juliangruber_changed nick to juliangruber
08:33:05  <rvagg>also, leveldb has a cache setting which is perhaps a bit underused, crank it right up and you should get something akin to redis (well... vaguely)
08:33:12  <dominictarr>juliangruber_: was telling me that if he ran the client and the server is separate processes then performance improved a lot
08:33:23  <juliangruber>ah, you're talking multilevel?
08:33:26  <dominictarr>yea
08:33:50  <juliangruber>https://github.com/juliangruber/multilevel#performance
08:33:59  <chapel>rvagg: well I assume larger is better, since its op/s
08:34:04  <dominictarr>really, we could apply the same level-* pattern to redis.
08:34:12  <dominictarr>redis could be a node module
08:34:31  <rvagg>chapel: yeah, totally
08:34:32  <jden>performance tricks and chicanery!
08:34:53  <chapel>rvagg: that would mean running leveldb is actually more performant
08:34:54  <jden>I'm really less concerend with performance, outside of maybe a couple of orders of magnitude
08:35:19  <chapel>jden: sure, its largely not a concern, but it is for some people
08:35:42  <dominictarr>it's just that it's objectively measurable (somewhat)
08:35:49  <chapel>dominictarr: actually thats something Ive thought about a lot, guess thats why I love leveldb
08:36:00  <dominictarr>so we can all stand around with the hood up and discuss...
08:36:06  <chapel>dominictarr: node is a great platform to build things like databases
08:36:10  <rvagg>"performance" is in the same category as "scalability", people use the words as a general handwavy way of dismissing something or questioning its value
08:36:15  <jden>dominictarr: that's a great image :)
08:36:16  <rvagg>but it's important to have reasonable answers
08:36:51  <chapel>rvagg: that is why ryah and isaacs after him focus on performance with node
08:37:10  <jden>performance is important, but it's not of overriding importance.
08:37:28  <jden>it's a secondary concern. "nail it and scale it" perf is the scale it part
08:37:32  <chapel>not because it matters when developing something, but because having an eye on it allows you to say it matters to those that care
08:37:44  <substack>dominictarr: sudoroom is completely taken with disasteradio now
08:37:47  <jden>it totally matters.
08:37:48  <substack>https://twitter.com/romyilano/status/333137454045462528/photo/1
08:37:55  <jden>it's just not the primary thing, ever.
08:37:57  <dominictarr>substack: what is sudoroom?
08:38:14  <jden>oakland hackerspace/*
08:38:21  <chapel>jden: its a diminishing level of improvement
08:38:23  <dominictarr>oh, nice
08:38:44  <substack>http://sudoroom.org/
08:39:11  <dominictarr>substack: I keep telling him to visit! he's toured the states, but only passed through the bay area...
08:39:15  <substack>new hackerspace in downtown oakland
08:39:34  <jden>chapel: this. it's the asymptotic part.
08:40:12  <jden>who's the old greek guy associated with this idea?
08:40:19  <chapel>jden: I mean, if performance was a true concern, you might as well develop in assembly, though, application performance isn't the only concern
08:40:33  <chapel>developer performance can be a huge part of any decisions being made
08:40:50  <jden>"human factors"
08:41:28  <chapel>in fact, most rules and systems we use as programmers are for us, not for machines
08:41:40  <chapel>since we are the weak link if you will
08:42:11  <dominictarr>it's like that is sailing too
08:42:18  <dominictarr>the boat will outlast you
08:42:41  <dominictarr>you have to plan to control your fatigue
08:42:51  <chapel>dominictarr: good example
08:43:00  <chapel>works well in the team environment as well
08:43:01  <dominictarr>because fatigued you are much more likely do make a poor decision
08:43:04  <jden>dominictarr: im using that in my nodepdx talk.
08:43:29  <dominictarr>great!
08:43:45  <chapel>since you all have your roles, and its about maximizing performance while minimizing fatigue to ensure highest quality
08:45:27  <jden>there's a good medical analogy
08:45:42  <jden>as a doctor, there's this (amorphous) notion of the "standard of care"
08:45:54  <jden>you're expected to treat each patient to a certain reasonable high standard
08:46:23  <jden>but it would be ridiculous to throw aside all of your responsibility and hyperoptimize care of a specific patient at the expense of all the others
08:46:39  <dominictarr>this concept is also called "fairness"
08:46:46  <jden>there's not necessarily a clear cut guideline here.
08:46:51  <jden>dominictarr: yes
08:46:58  <jden>it's not necessarily an optimization problem
08:47:24  <dominictarr>well, it sort of is,
08:47:43  <jden>it is, except in how you account for the metrics
08:47:59  <dominictarr>but it's different, because if it was simply maximizing care
08:48:21  <dominictarr>it could be like jamming one traffic light green.
08:48:26  * dguttmanquit (Quit: dguttman)
08:48:37  <jden>the assumption is that the professional discretion (Dreyfuss model would call it expert intuition) tends to optimize over the entire career, rather than the immediate short term
08:48:55  <dominictarr>yes
08:49:25  <dominictarr>I heard an interesting talk about fairness in TCP, a while ago
08:49:49  <jden>I guess when I said it wasn't an optimization problem, I meant it wasn't a closed world optimization problem
08:49:59  <dominictarr>jden: agree
08:50:06  <dominictarr>that is a better way to put it.
08:52:54  <jden>dominictarr: are you coming to nodeconf?
08:53:03  <dominictarr>yes!
08:53:25  <jden>excellent!
08:55:30  <dominictarr>I'm gonna organize a leveldb meetup while I'm in town too
08:56:17  <jden>cool, let me know. I need to carve out some time at some point to dive into leveldb. I've seen you and rvagg doing a ton of work building modules around it. just haven't had time to give it the proper attention
08:56:38  <jden>also: you should make stickers. that's a very real form of social currency
08:56:45  <jden>I'd be happy to buy some
08:57:22  <chapel>dominictarr: when is that?
08:57:35  <rvagg>aww, a leveldb meetup! perhaps I need to try and talk cian in to funding a trip over for me
08:57:43  <rvagg>tho I think nodeconf tickets might be gone already
08:58:11  * chapelcan't afford nodeconf :(
08:58:25  <dominictarr>chapel: end of june
08:58:32  <jden>heh, site's not responding for me
08:58:38  <rvagg>stick a www in front
08:58:42  <chapel>dominictarr: would you be doing the leveldb stuff outside of nodeconf?
08:58:48  <dominictarr>I know, lol, right
08:58:59  <chapel>cause I'd love come if so
08:59:12  <dominictarr>chapel: yes that is the plan.
08:59:28  <jden>https://twitter.com/nodeconf/status/332549901533708288
08:59:29  <chapel>dominictarr: sweet, I guess I'll just watch in here
09:00:45  <jden>chapel: walmart not give you a conf allowance?
09:00:55  <chapel>jden: I haven't started yet
09:01:13  <jden>ah
09:01:19  <chapel>jden: tickets sold out early on and I was short on funds when the tickets were available
09:01:49  <jden>the next month or so is going to be a whirlwind of conf season for me. nodepdx, then jsconf, then oscon, the nodeconf
09:04:29  <jden>the next minute or so is going to be a whirlwind of me going to bed - thanks, all for helping me understand the concepts of leveldb better
09:09:25  <rvagg>hij1nx: leveldb stickers! hand em out at nodeconf
09:19:13  <tanepiper>dominictarr: hey man! You missed a good night last night
09:19:47  <tanepiper>we broke github's tab in 2 1/2 hours
09:21:06  <dominictarr>tanepiper: I wanted to stay, but I was too hung over from night before
09:21:21  <dominictarr>I had a first beer, and then just felt sick :(
09:25:04  <tanepiper>fair enough - i only had a couple the night before so I wasn't too bad :)
09:57:55  * nicholasfjoined
09:57:56  <dominictarr>tanepiper: are you going to the nodecopter thing?
09:58:12  <dominictarr>I'm just about to shower and have breakfast, then head down...
10:03:09  <jesusabdullah>*sigh*
10:03:16  <jesusabdullah>I'm kind of sad that I couldn't go
10:03:27  <jesusabdullah>but I also know I'd be tired, jet lagged and grouchy
10:03:35  <jesusabdullah>I do not know which is better
10:03:38  <jesusabdullah>at least I have star trek
10:10:07  <tanepiper>dominictarr: nahh got stuff to do
10:12:09  <dominictarr>currently running lvl1 diagnostic on jesusabullah's decision not to go to scotland.js....
10:19:45  * ralphtheninjajoined
10:26:57  * dominictarrquit (Quit: dominictarr)
10:36:59  * nicholasfquit (Read error: Connection reset by peer)
10:37:12  * nicholasfjoined
10:49:26  <substack>http://www.youtube.com/watch?v=4M-KfV4qTgw
10:59:46  <ralphtheninja>substack: ploy looks sweet!
11:42:12  <tanepiper>oh thanks for reminding me about exterminate!
11:52:31  * dominictarrjoined
11:55:14  <ralphtheninja>substack: hehe just noticed a problem with exterminate .. I'm using vimium for chrome so I can navigate vimstyle in the browser .. and the 'x' key is mapped to close a tab .. so if want to type 'xtshow ..' the first 'x' closes exterminate :)
11:59:41  <ralphtheninja>dominictarr: sup? had a good time on scotlandjs?
12:00:11  <dominictarr>ralphtheninja: yes!
12:00:20  <dominictarr>people liked my level- talk too
12:00:27  <ralphtheninja>nice!
12:00:50  <ralphtheninja>hopefully it made them able to levelup .. pun intended!
12:03:21  * ins0mniajoined
12:04:59  <ins0mnia>dominictarr: ping
12:05:48  <dominictarr>ins0mnia: yo
12:12:17  * wolfeidauquit (Remote host closed the connection)
12:23:05  <tanepiper>dominictarr: It was a great talk, but one thing - I think they put you on at the wrong time
12:23:13  <tanepiper>It was a bit technical for the last talk of the day
12:23:59  <tanepiper>(but that's not a criticism of the talk itself - I just didn't take it all in) - but it's been recorded so I can go back and watch it
12:24:23  <tanepiper>the whole Sublevel stuff is exactly what I need to look at - as well as the key separation stuff
12:24:47  <ralphtheninja>a good talk should be like a good movie .. should leave you wondering about the plot :)
12:25:21  <dominictarr>tanepiper: yes, agree
12:44:18  <ralphtheninja>dominictarr ins0mnia walking my dog, bbiab
12:54:16  * nicholasfquit (Read error: Connection reset by peer)
12:54:31  * nicholasfjoined
13:07:18  * nicholasfquit (Read error: Connection reset by peer)
13:07:42  * nicholasfjoined
13:21:42  * ins0mniaquit (Ping timeout: 272 seconds)
13:25:12  * ins0mniajoined
13:26:54  * timoxleyquit (Quit: Computer has gone to sleep.)
13:42:21  <dominictarr>ralphtheninja: just working on some stuff to pull down npm packages, preserving hashes
13:42:52  <ralphtheninja>dominictarr: nice
13:42:56  <dominictarr>at scotland.js No9 changed his talk and implemented bit torrent deployment the night before instead...
13:43:03  <ralphtheninja>lol
13:43:16  <dominictarr>so maybe it will be really easy to do that actually!
13:50:37  <ralphtheninja>dominictarr: are you leaving for sweden tomorrow or on monday?
13:51:01  <dominictarr>monday
13:51:06  <ralphtheninja>
13:51:24  <dominictarr>I'm landing in stockholm quite late, after 9 pm
13:51:33  <dominictarr>so i'll stay there that night, then come and meet you
13:51:38  <dominictarr>the next day
13:51:46  <ralphtheninja>cool
13:57:26  * nicholasfquit (Read error: Connection reset by peer)
13:57:45  * nicholasfjoined
14:08:46  * mikolalysenkojoined
14:30:28  * vitorpachecoquit (Remote host closed the connection)
14:42:12  * vitorpachecojoined
14:46:26  * simcop2387quit (Excess Flood)
14:46:29  * ins0mniaquit (Ping timeout: 252 seconds)
14:49:19  * dfggquit (Ping timeout: 264 seconds)
14:49:34  * dfggjoined
14:49:38  * simcop2387joined
14:51:17  * ralphthe1injajoined
14:51:18  * ins0mniajoined
14:51:46  * ralphtheninjaquit (Ping timeout: 264 seconds)
15:00:07  * ralphthe1injachanged nick to ralphtheninja
15:05:11  <FireFly>Is there anything JS-related happening in Stockholm? :o
15:06:12  * mikolalysenkoquit (Ping timeout: 272 seconds)
15:10:43  <dominictarr>FireFly: just some js people meeting up!
15:10:50  <dominictarr>why, are you in stockholm?
15:10:58  <FireFly>Yup
15:11:02  <FireFly>Well, 30 min outside of it
15:13:54  <dominictarr>cool! we should meet up, I'm arriving in stockholm late on the 13th
15:14:03  <dominictarr>but we could meet up in the morning
15:14:08  <dominictarr>of the 14th
15:20:36  * nicholasfquit (Read error: Connection reset by peer)
15:20:44  * nicholasfjoined
15:24:40  * jaz303_joined
15:27:34  * ralphtheninjaquit (Ping timeout: 245 seconds)
15:27:35  * ralphtheninjajoined
15:29:58  * jaz303quit (*.net *.split)
15:29:58  * jesusabdullahquit (*.net *.split)
15:30:46  * jesusabdullahjoined
15:31:07  * jaz303_changed nick to jaz303
15:33:35  * ralphtheninjaquit (Ping timeout: 245 seconds)
15:34:02  * ralphtheninjajoined
15:37:52  * nicholasfquit (Read error: Connection reset by peer)
15:38:08  * nicholasfjoined
15:45:18  * mcollinajoined
15:48:34  * mikolalysenkojoined
15:55:39  * AvianFluquit (Remote host closed the connection)
16:06:21  * stagasquit (Read error: Connection reset by peer)
16:08:36  * thl0joined
16:17:06  * ralphtheninjaquit (Ping timeout: 245 seconds)
16:27:40  * dominictarrquit (Quit: dominictarr)
16:28:23  * jan____quit (*.net *.split)
16:28:23  * CoverSli1equit (*.net *.split)
16:28:23  * creationixquit (*.net *.split)
16:28:59  * jan____joined
16:28:59  * CoverSli1ejoined
16:28:59  * creationixjoined
16:30:06  * CoverSli1equit (Remote host closed the connection)
16:30:14  * CoverSlidejoined
16:31:15  * thl0quit (Remote host closed the connection)
16:32:40  * fotoveritequit (Quit: fotoverite)
16:33:28  * mikolalysenkoquit (Ping timeout: 245 seconds)
16:39:26  * xyxnejoined
16:40:22  * elliottcablequit (Ping timeout: 256 seconds)
16:40:22  * Nexxyquit (Ping timeout: 256 seconds)
16:40:59  * gildeanquit (Ping timeout: 256 seconds)
16:41:05  * elliottcablejoined
16:41:53  * blobaum_joined
16:42:21  * gildeanjoined
16:42:27  * blobaumquit (Ping timeout: 256 seconds)
16:47:25  * mikolalysenkojoined
16:48:04  * yorickjoined
16:51:57  * dguttmanjoined
16:53:44  * Madars_joined
16:53:52  * Madarsquit (Ping timeout: 256 seconds)
16:56:00  * mikolalysenkoquit (Ping timeout: 264 seconds)
17:04:05  * dguttmanquit (Quit: dguttman)
17:07:21  * harrow`joined
17:07:38  * vitorpachecoquit (*.net *.split)
17:07:39  * munroquit (*.net *.split)
17:07:39  * rvaggquit (*.net *.split)
17:07:39  * FireFlyquit (*.net *.split)
17:07:40  * elliottcable_quit (*.net *.split)
17:07:40  * harrowquit (*.net *.split)
17:07:40  * brianloveswordsquit (*.net *.split)
17:08:03  * brianloveswordsjoined
17:09:33  * rvaggjoined
17:13:47  * munrojoined
17:14:48  * vitorpachecojoined
17:15:48  * FireFlyjoined
17:16:36  * elliottcable__joined
17:37:18  * thl0joined
17:44:31  * thl0quit (Remote host closed the connection)
17:47:29  * rvagg_joined
17:50:58  * rvaggquit (*.net *.split)
17:50:59  * rvagg_changed nick to rvagg
18:02:08  * mikolalysenkojoined
18:06:41  * mikolalysenkoquit (Ping timeout: 245 seconds)
18:07:18  * fotoveritejoined
18:07:21  * rowbit1joined
18:07:21  * rowbit1quit (Remote host closed the connection)
18:07:25  * Raynos_joined
18:08:39  * nicholasfquit (Read error: Connection reset by peer)
18:08:48  * nicholasfjoined
18:08:58  * ralphtheninjajoined
18:09:04  * calvinfo_joined
18:09:57  * CoJaBo_joined
18:10:12  * perlbot_joined
18:10:26  * chilts_joined
18:14:18  * gildeanquit (*.net *.split)
18:14:18  * xyxnequit (*.net *.split)
18:14:19  * pikpikquit (*.net *.split)
18:14:19  * mint_xianquit (*.net *.split)
18:14:19  * johnkpaulquit (*.net *.split)
18:14:19  * tim_smartquit (*.net *.split)
18:14:19  * juliangruberquit (*.net *.split)
18:14:20  * Guest24902quit (*.net *.split)
18:14:20  * sorensenquit (*.net *.split)
18:14:21  * niftylettucequit (*.net *.split)
18:14:21  * duncanbeeversquit (*.net *.split)
18:14:21  * elliottcable__quit (*.net *.split)
18:14:21  * harrow`quit (*.net *.split)
18:14:22  * jolissquit (*.net *.split)
18:14:22  * jlord_quit (*.net *.split)
18:14:22  * zuquit (*.net *.split)
18:14:23  * mirkokquit (*.net *.split)
18:14:23  * farnsworthquit (*.net *.split)
18:14:23  * cubertquit (*.net *.split)
18:14:23  * purrquit (*.net *.split)
18:14:24  * Raynosquit (*.net *.split)
18:14:24  * rannmannquit (*.net *.split)
18:14:24  * mbalhoquit (*.net *.split)
18:14:25  * chiltsquit (*.net *.split)
18:14:25  * perlbotquit (*.net *.split)
18:14:25  * rowbitquit (*.net *.split)
18:14:25  * paul_irishquit (*.net *.split)
18:14:25  * CoJaBoquit (*.net *.split)
18:14:25  * nk109quit (*.net *.split)
18:14:25  * calvinfoquit (*.net *.split)
18:14:26  * hij1nxquit (*.net *.split)
18:14:26  * LOUDBOTquit (*.net *.split)
18:14:26  * perlbot_changed nick to perlbot
18:29:21  * paul_irishjoined
18:30:51  * rannmannjoined
18:30:51  * mbalho_joined
18:30:51  * gildeanjoined
18:30:51  * xyxnejoined
18:30:51  * pikpikjoined
18:30:51  * mint_xianjoined
18:33:56  * elliottcable__joined
18:33:56  * harrow`joined
18:33:56  * jolissjoined
18:33:56  * jlord_joined
18:33:56  * zujoined
18:33:56  * mirkokjoined
18:33:56  * farnsworthjoined
18:33:56  * cubertjoined
18:33:56  * purrjoined
18:34:07  * mikolalysenkojoined
18:36:14  * johnkpauljoined
18:36:14  * tim_smartjoined
18:36:14  * juliangruberjoined
18:36:14  * Guest24902joined
18:36:14  * sorensenjoined
18:36:14  * niftylettucejoined
18:36:14  * duncanbeeversjoined
18:39:44  * fotoveritequit (Quit: fotoverite)
18:44:14  * mbalho_quit (*.net *.split)
18:44:15  * gildeanquit (*.net *.split)
18:44:15  * xyxnequit (*.net *.split)
18:44:15  * pikpikquit (*.net *.split)
18:44:16  * mint_xianquit (*.net *.split)
18:44:16  * rannmannquit (*.net *.split)
18:49:57  * rannmannjoined
18:49:57  * mbalho_joined
18:49:57  * gildeanjoined
18:49:57  * xyxnejoined
18:49:57  * pikpikjoined
18:49:57  * mint_xianjoined
18:50:59  * Raynos_quit (Changing host)
18:51:00  * Raynos_joined
19:00:29  * calvinfo_quit (Read error: Connection reset by peer)
19:00:58  * calvinfo_joined
19:02:34  * stagasjoined
19:14:19  * rannmannquit (*.net *.split)
19:20:45  * jcrugzzjoined
19:25:13  <ralphtheninja>any recommendations what to do if I want to browserify some stuff that's doing e.g. require('stream').Readable from node 0.10+
19:26:17  * thl0joined
19:35:04  * calvinfo_quit (Ping timeout: 245 seconds)
19:44:52  * nicholasfquit (Read error: Connection reset by peer)
19:45:06  * nicholasfjoined
19:47:42  * jcrugzzquit (Quit: leaving)
19:49:13  * jcrugzzjoined
19:50:53  * rannmannjoined
19:51:36  * calvinfo_joined
19:56:17  * jcrugzzquit (Quit: leaving)
19:58:44  * dfggchanged nick to dfgg_
20:00:43  * dfgg_changed nick to dfgg
20:15:56  <mbalho_>ralphtheninja: im pretty sure browserify still uses 0.8 streams and nobody has figured out how to browserify the new stuff
20:21:25  * vitorpachecoquit (Ping timeout: 248 seconds)
20:22:28  * hij1nxjoined
20:26:15  <ralphtheninja>mbalho_: I had a hunch that was the case, thanks!
20:26:39  <yorick>I have the feeling the substack modules are gonna be on 0.10 right around when 0.12 is coming out
20:27:19  <yorick>but I'm not even sure, he's still making new 0.8-only modules
20:28:23  * vitorpachecojoined
20:30:28  * mbalhojoined
20:31:03  * pikpikquit (Ping timeout: 276 seconds)
20:31:05  * mbalho_quit (Remote host closed the connection)
20:31:05  * gildeanquit (Ping timeout: 276 seconds)
20:31:22  * gildeanjoined
20:38:34  * Nexxyjoined
20:40:42  * nicholasfquit (Read error: Connection reset by peer)
20:40:52  * nicholasfjoined
20:42:38  * xyxnequit (*.net *.split)
20:42:38  * mint_xianquit (*.net *.split)
20:44:36  * nicholasfquit (Read error: Connection reset by peer)
20:45:01  * nicholasfjoined
20:55:11  * jcrugzzjoined
21:01:16  * mint_xianjoined
21:08:40  * jlord_changed nick to jlord
21:14:26  * mikolaly1enkojoined
21:16:51  * mbalho_joined
21:18:20  * dsfadfjoined
21:20:44  * wolfeidaujoined
21:23:31  * brianloveswords_joined
21:23:57  * ricardobeatjoined
21:24:08  * mbalhoquit (*.net *.split)
21:24:08  * rannmannquit (*.net *.split)
21:24:08  * mikolalysenkoquit (*.net *.split)
21:24:09  * brianloveswordsquit (*.net *.split)
21:25:09  * vitor_joined
21:25:31  * vitorpachecoquit (Ping timeout: 264 seconds)
21:25:31  * rvaggquit (Ping timeout: 264 seconds)
21:25:31  * elliottcablequit (Ping timeout: 264 seconds)
21:25:54  * chilts_quit (Ping timeout: 264 seconds)
21:26:16  * CoverSlidequit (Remote host closed the connection)
21:26:19  * chiltsjoined
21:26:33  * ricardobeatquit (Remote host closed the connection)
21:27:11  * dsfadfchanged nick to rannmann
21:29:02  * CoverSlidejoined
21:29:02  * elliottcablejoined
21:29:02  * rvaggjoined
21:29:05  * ricardo_joined
21:29:17  * CoverSlidequit (Max SendQ exceeded)
21:29:17  * elliottcablequit (Max SendQ exceeded)
21:30:09  * elliottcablejoined
21:31:25  * CoverSlidejoined
21:35:49  * wolfeidauquit (Remote host closed the connection)
21:48:15  * brianloveswords_changed nick to brianloveswords
21:49:07  * brianloveswordsquit (Max SendQ exceeded)
21:51:01  * brianloveswordsjoined
22:02:53  * substacktopic: Unofficial browserling/testling mad science channel. For official help /join #browserling
22:03:02  * nicholasfquit (Read error: Connection reset by peer)
22:03:14  <substack>yorick: don't even bother with 0.10
22:03:15  * nicholasfjoined
22:03:32  <yorick>substack: now what's wrong with 0.10?
22:03:39  <substack>0.10 just broke everything for no reason
22:03:54  * jcrugzzquit (Ping timeout: 256 seconds)
22:04:14  <yorick>fixed at lot of stream caveats
22:04:26  * mcollina_joined
22:04:28  <yorick>and they say they maintained compatibility as best as possible
22:05:01  <substack>the combination of stream changes and nextTick changes has been brutal
22:05:08  <substack>so many new timing bugs
22:06:11  <yorick>substack: it's still the future, though, we can't not bother with the future
22:06:16  <substack>I'm just going to keep using 0.8
22:07:06  <substack>if somebody can figure out how to fix browserify for the new streams noise I'll take a pull request
22:07:26  <yorick>where will we get our awesome modules from :O
22:07:36  <substack>`nave use 0.8`
22:08:15  * st_lukejoined
22:08:43  <substack>streams2 are basically just a boring performance optimization that I don't care about
22:08:52  <substack>and they broke all my modules
22:08:53  <substack>so fuck them
22:09:24  <yorick>substack: that's not the rationale for streams2, have you seen the slides and read the blogpost?
22:09:39  * CoJaBo_quit (Disconnected by services)
22:10:02  * mcollinaquit (*.net *.split)
22:10:02  * slurp1quit (*.net *.split)
22:11:22  <substack>they let you pull from resources instead of being pushed at and simplify pause/resume (but add complexity elsewhere)
22:11:32  <substack>but I don't even care because I just use modules for that
22:12:43  * shadghostquit (Ping timeout: 256 seconds)
22:13:29  * CoJaBo-Aztecjoined
22:13:41  * shadghostjoined
22:14:15  * CoJaBo-Aztecquit (Disconnected by services)
22:14:20  * LOUDBOTjoined
22:19:49  * jcrugzzjoined
22:22:20  <tanepiper>fork 0.8 and create a new node dist!
22:22:37  * CoJaBojoined
22:22:46  <mikolaly1enko>I think I can confidently say that I don't really understand streams 2. I'm just going to wait until everything settles down a bit before trying to do much with them...
22:24:00  <mikolaly1enko>I think idea of pull instead of push is pretty nice though
22:24:38  <ricardo_>streams in v0.10 are still backwards-compatible, with a few caveats
22:25:08  <mikolaly1enko>yes, but those caveats make them not really compatible
22:25:12  <yorick>tanepiper: your idea is bad and you should feel bad. let's take a perfectly fine ecosystem and shatter it?
22:25:25  <yorick>mikolaly1enko: the only caveat is that you need to add a data handler?
22:25:38  <tanepiper>yorick: I am lolling from you under the bridge
22:25:46  <tanepiper>*at you
22:26:04  <mikolaly1enko>yorick: I'm not sure that's the only caveat...
22:26:21  <mikolaly1enko>like the way you would use a 1.0 stream is very different than the way you'd use a 2.0 stream
22:26:23  <yorick>mikolaly1enko: it's the only one they thought there would be
22:26:36  <mikolaly1enko>the performance and semantics are pretty different
22:26:42  <yorick>tanepiper: ..what?
22:26:43  * tmcwjoined
22:26:45  <mikolaly1enko>push and pull are two different approaches to io
22:26:56  <tanepiper>yorick: i was trolling
22:27:14  <yorick>tanepiper: you should be very afraid of the idea
22:27:32  <yorick>mikolaly1enko: the emulation is rather OK it seems
22:27:33  <tanepiper>yorick: tbh I'm surprised it hasn't happened already
22:27:35  <mikolaly1enko>I almost wish that they had just made a different module and called it pull-stream or something like that instead of replacing stream in place
22:27:38  <yorick>(either that or their tests are bad)
22:27:49  <yorick>https://github.com/dominictarr/pull-stream there? :P
22:28:15  <mikolaly1enko>well, not that pull stream but you know what I mean
22:28:22  <ricardo_>mikolaly1enko: that's how it was done. streams2 was in development for many months before it made it into v0.10
22:28:31  * pikpikjoined
22:29:02  <mikolaly1enko>I don't know, I am just confused by it all so maybe the stuff I am saying is nonsense
22:29:22  <ricardo_>https://github.com/isaacs/readable-stream
22:30:37  <yorick>All the planning charts and demolition orders have been on display at your local planning department at nodejs.org for four of your Earth months, so you've had plenty of time to lodge any formal complaint and it's far too late to start making a fuss about it now
22:31:04  <mikolaly1enko>right, I guess I am not really upset about it one way or the other
22:31:14  <mikolaly1enko>I am just confused by it all
22:31:36  <mikolaly1enko>my approach is that I tend to avoid streams in my own projects because I am not sure that I trust them that much
22:31:40  <yorick>http://blog.nodejs.org/2012/12/20/streams2/ guess the world ended after all :P
22:32:40  <mikolaly1enko>for me, the weirdest thing about streams 2 is that they try to be streams 1 compatible
22:32:56  <mikolaly1enko>like they start in this weird state, but once you add some stuff to them they magically transform into a streams 2 stream
22:33:15  <mikolaly1enko>which is not very explicit, and confuses me since the specific circumstances are rather opaque
22:33:19  <yorick>mikolaly1enko: no, they magically transform into a streams 1 stream when you add a data handler
22:33:25  <mikolaly1enko>ok
22:33:52  <yorick>and they start out as paused streams 2 streams
22:34:04  <mikolaly1enko>that makes some sense
22:34:20  <mikolaly1enko>so, it is streams 2 stream, add handler -> magical streams 1 downgrade
22:34:34  <yorick>yeah
22:34:56  <mikolaly1enko>in a streams 2 stream, should you ever add the data handler?
22:35:01  <yorick>nope
22:35:40  <yorick>you get things from it by calling .read([size]), and it returns things (or null, where you should wait for 'readable')
22:35:45  <mikolaly1enko>if I write an app that uses a streams 2 stream, can I pass it a streams 1 stream?
22:36:38  <yorick>mikolaly1enko: well, I guess when it's in old mode the newfangled ways won't really work
22:36:45  <yorick>but you could still .pipe from/to it
22:36:49  <mikolaly1enko>hmm
22:37:51  <mikolaly1enko>so my previous understanding of streams was that they were basically event emitters with a special protocol that allows you to pipe stuff and handle errors
22:38:08  <mikolaly1enko>ie data for packet, end for stop, drain for unpause, and error for error event
22:39:46  <yorick>mikolaly1enko: now, it emits 'readable', and then you can call read to get the data
22:40:00  <mikolaly1enko>ok
22:40:14  <mikolaly1enko>so, before if I made a 1.0 stream that starts paused
22:40:24  <mikolaly1enko>and add a drain event listener for the unpause
22:40:42  <mikolaly1enko>then will it downgrade to a 1.0 stream correctly in streams2?
22:41:08  <yorick>to get a streams2 stream out of an 'old' one, you can do (new (require('stream').Readable)).wrap(oldstream)
22:41:24  <mikolaly1enko>hmm
22:41:40  <mikolaly1enko>will the old stream stuff get deprecated eventually?
22:41:49  <yorick>hopefully
22:41:52  <mikolaly1enko>ok
22:42:04  <mikolaly1enko>node going to 1.0 with that stuff still in seems like a bad deal
22:45:22  <substack>there's so much surface area in the new stream api
22:45:31  <mikolaly1enko>maybe they should have just made a module called "queue" or something
22:45:42  <mikolaly1enko>since this is basicall a producer/consumer problem, except without threads
22:46:00  * dsfadfjoined
22:46:02  * rannmannquit (Disconnected by services)
22:46:02  * dsfadfchanged nick to rannmann
22:46:02  * rannmannquit (Changing host)
22:46:02  * rannmannjoined
22:46:07  <mikolaly1enko>or maybe call it FIFO
22:46:34  <mikolaly1enko>or "channel" like go
22:46:57  <substack>whatever, streams1 were good enough
22:47:18  * ins0mniaquit (Ping timeout: 256 seconds)
22:47:23  <mikolaly1enko>well, a pull interface makes sense; and fifos are important
22:48:25  <mikolaly1enko>another possible solution might be to make streams totally unbuffered
22:48:27  * ryanseddonquit (Ping timeout: 256 seconds)
22:48:58  <mikolaly1enko>with "yield" you could do that, just have the producer block until the consumer pulls something out
22:49:30  * ins0mniajoined
22:49:35  <mikolaly1enko>though this is a pretty basic problem and has tons of solutions (see wiki for example: http://en.wikipedia.org/wiki/Producers-consumers_problem )
22:49:54  * yorick_joined
22:50:11  * perlbot_joined
22:50:17  <substack>or just emit 'data' and 'end' and have a mechanism to instruct the other end to start and stop emitting events
22:50:20  <substack>so simple
22:50:25  * mcollinajoined
22:50:42  <mikolaly1enko>yes, but you also need to have some way to buffer events
22:50:53  <mikolaly1enko>or else you get race conditions which can cause you to lose data
22:51:00  <substack>that's a user-land problem
22:51:03  * ralphthe1injajoined
22:51:10  * thl0quit (Remote host closed the connection)
22:51:13  <substack>require('through')
22:51:25  <mikolaly1enko>actually, here is a better idea:
22:51:29  <mikolaly1enko>replace all streams with through
22:51:50  <substack>that's basically what I do already
22:52:02  <yorick_>substack: if everyone needs to use a module for things to work nicely then the core node.js has failed
22:52:07  <mikolaly1enko>me too, at least whenever I can't avoid using streams in the first place
22:52:10  <substack>streams are not actually a good api
22:52:23  <substack>streams and duplexer
22:52:27  <substack>*through and duplexer
22:52:30  <substack>pretty much all you need
22:52:35  <mikolaly1enko>the concept is ok, but the api is awkward
22:53:18  <substack>basically if you try to write a stream using the core api you are going to fuck it up
22:53:24  <substack>it's so impossibly hard to do it correctly
22:53:56  <mikolaly1enko>well, I won't say it is impossible; but I personally agree that I find it very confusing and difficult
22:54:16  <mikolaly1enko>but I am not convinced that this isn't just my own problem
22:54:28  <mikolaly1enko>and perhaps after working with it a bit more it gets easier
22:54:50  <substack>I don't have that kind of patience
22:55:05  <substack>if I can't get something working after reading the docs and playing around with it it's probably not very good
22:55:07  * stagas_joined
22:55:30  <mikolaly1enko>maybe. who is using streams 2 now besides core node developers?
22:55:34  <substack>comprehensibility is a very important metric by which apis should be judged
22:55:37  <substack>exactly
22:55:41  * perlbotquit (Ping timeout: 256 seconds)
22:55:41  * mcollina_quit (Ping timeout: 256 seconds)
22:55:41  * ralphtheninjaquit (Ping timeout: 256 seconds)
22:55:41  * perlbot_changed nick to perlbot
22:55:42  * yorickquit (Ping timeout: 256 seconds)
22:55:42  <substack>nobody
22:55:45  * calvinfo_quit (Ping timeout: 256 seconds)
22:55:45  * stagasquit (Ping timeout: 256 seconds)
22:55:58  * stagas_changed nick to stagas
22:56:30  * calvinfo_joined
22:57:07  * jesusabdullahquit (Remote host closed the connection)
22:57:09  <mikolaly1enko>yeah. I don't know what the best solution to this problem will be
22:58:45  * yorickjoined
22:59:44  <mikolaly1enko>I think though that starting out paused, and buffering by default is a good choice. and some mechanism to implement backpressure is necessary as well
23:01:06  * ralphthe1injachanged nick to ralphtheninja
23:02:51  <mikolaly1enko>so, in csp they solve this stuff with sequential channels. though that choice may be motivated more on religious grounds than on any practical consideration
23:04:29  * tmcwquit (Remote host closed the connection)
23:05:34  * yorick_quit (*.net *.split)
23:07:29  <mcollina>mikolaly1enko: I'm using stream2. The spec is totally incomprehensible, but you inherit from Writable, Readable or Transform, and you are done.
23:07:58  * jesusabdullahjoined
23:09:14  <mikolaly1enko>mcollina: do you have some examples?
23:10:18  <mcollina>https://github.com/mcollina/callback-stream/blob/master/index.js and https://github.com/mcollina/node-levelgraph/blob/master/lib/keyfilterstream.js
23:12:10  <mikolaly1enko>mcolina: no offense, but that seems really complicated
23:12:52  <mikolaly1enko>for example, why do you have to make a custom pipe event handler?
23:12:57  * nicholasfquit (Read error: Connection reset by peer)
23:13:18  * nicholasfjoined
23:14:20  <mcollina>Because I want the error from the parent stream in my callback.
23:15:21  * st_lukequit (Remote host closed the connection)
23:16:16  * jolissquit (Quit: joliss)
23:17:01  <mcollina>Or because I just want to know who is uphill.
23:17:44  <ralphtheninja>I agree on streams2, the api is weird
23:18:33  <mcollina>But everything is already handled by Readable, Writable and Transform.
23:18:40  <ricardo_>I'm using it here https://github.com/ricardobeat/stream-bucket/blob/master/index.js
23:18:48  <ricardo_>simple enough
23:18:53  <ralphtheninja>ricardo_: heya :)
23:19:02  <ricardo_>ralphtheninja: hi :)
23:19:31  * owenb_joined
23:20:06  <mikolaly1enko>I just keep getting hung up when I try to consider all the edge cases for writing streams 2 code
23:20:29  <mikolaly1enko>anyway, I'll study it some more later. I have other stuff to work on for now
23:22:42  * yorickquit (Remote host closed the connection)
23:23:00  * jolissjoined
23:23:12  * owenbquit (Ping timeout: 264 seconds)
23:23:15  * owenb_changed nick to owenb
23:23:24  <mbalho_>jlord: check out http://www.pdxlivebus.com/ code https://github.com/browniefed/livemet
23:23:34  <mbalho_>jlord: they used some weird framework i have never heard of though
23:24:02  * tmcwjoined
23:25:29  * heathjsjoined
23:26:49  * lepahcjoined
23:27:50  * rook2paw1quit (*.net *.split)
23:27:50  * jjjjohnnnyquit (*.net *.split)
23:27:50  * dools_quit (*.net *.split)
23:27:50  * Raltquit (*.net *.split)
23:27:50  * heathquit (*.net *.split)
23:27:50  * Domenic_quit (*.net *.split)
23:27:50  * sveisveiquit (*.net *.split)
23:27:50  * chapelquit (*.net *.split)
23:27:52  * lepahcchanged nick to chapel
23:30:59  * rook2pawnjoined
23:31:19  * dools_joined
23:31:20  * Raltjoined
23:31:54  * jjjjohnnnyjoined
23:33:47  * st_lukejoined
23:34:19  <jlord>mbalho_: woah bus
23:34:40  * tmcw_joined
23:37:06  * st_luke_joined
23:37:40  * jez0990_joined
23:37:51  * py1hon_joined
23:38:00  * ricardo_quit (*.net *.split)
23:38:00  * mbalho_quit (*.net *.split)
23:38:00  * gildeanquit (*.net *.split)
23:38:01  * hij1nxquit (*.net *.split)
23:38:01  * Raynos_quit (*.net *.split)
23:38:01  * Madars_quit (*.net *.split)
23:38:01  * jan____quit (*.net *.split)
23:38:02  * creationixquit (*.net *.split)
23:38:47  * tmcwquit (Ping timeout: 256 seconds)
23:43:34  * gildeanjoined
23:45:13  * st_lukequit (*.net *.split)
23:45:14  * jez0990quit (*.net *.split)
23:45:14  * crankquit (*.net *.split)
23:45:14  * py1honquit (*.net *.split)
23:45:39  * mikolaly1enkoquit (Quit: Reconnecting)
23:45:45  * mikolalysenkojoined
23:47:50  * crankjoined
23:49:40  * mbalhojoined
23:50:53  * ricardo_joined
23:50:53  * hij1nxjoined
23:50:53  * Raynos_joined
23:50:53  * jan____joined
23:50:53  * creationixjoined
23:51:12  * Madarsjoined
23:51:56  * Madarschanged nick to Guest3432
23:57:05  * dominictarrjoined