00:00:29  * kenansulaymanjoined
00:02:14  * esundahlquit (Ping timeout: 240 seconds)
00:04:24  * jerrysvquit (Remote host closed the connection)
00:12:44  * thlorenzjoined
00:23:28  * DTrejojoined
00:30:52  * jxson_quit (Remote host closed the connection)
00:34:55  * timoxleyjoined
00:35:22  * ednapiranhajoined
00:40:54  * thlorenzquit (Remote host closed the connection)
00:45:19  <rvagg>Sublime Text 3 is using LevelDB internally
00:45:37  <rvagg>just noticed a db in the Index directory of the user config
00:46:03  <kenansulayman>rvagg wut
00:46:18  <kenansulayman>not here?
00:46:47  <rvagg>here?
00:46:58  <kenansulayman>in my installation
00:47:31  <kenansulayman>ow
00:47:43  <kenansulayman>rvagg Sublime Text 3/Index?
00:48:11  <kenansulayman>we could make lev run over it
00:48:15  <rvagg>~/.config/sublime-text-3/Index
00:48:32  <rvagg>I tried to look in it with lev but it got stuck and I gave up,
00:48:44  <rvagg>I don't care enough, it's called "Index" so I don't imagine it to be particularly interesting
00:48:55  <rvagg>but it is quite large..
00:48:59  * thlorenzjoined
00:49:06  <kenansulayman>4 mb
00:49:29  <rvagg>38M for me, you're obviously not a hard-core coder!
00:49:36  <kenansulayman>:(
00:49:50  <kenansulayman>using Sublime Text 3 only for 4 weeks :>
00:50:14  <kenansulayman>@lev maybe cause the keys are binary and it fails to render properly?
00:50:55  * ednapiranhaquit (Remote host closed the connection)
00:53:02  * thlorenzquit (Ping timeout: 240 seconds)
00:54:47  <chapel>I use vim :P
00:58:55  <kenansulayman>chapel [00:41:07] <chapel> why go the hard route for something so trivial?
00:59:10  <chapel>its not hard
00:59:18  <chapel>and its far from trivial :P
01:00:00  <chapel>think of it like automation, once, or a few times doing something is fine, but after that I like to automate as much as possible
01:00:09  <chapel>vim for me is automation for tedious things
01:00:15  <kenansulayman>if you get used to it, might be
01:00:16  <kenansulayman>rvagg http://data.sly.mn/Rw4m
01:01:40  <rvagg>kenansulayman: I have absolutely no clue what's being indexed there
01:02:47  <kenansulayman>seems like fast type lookup of files
01:03:19  <kenansulayman>since same-type entries are prefixed with the same binary sequence
01:09:33  * julianduquequit (Quit: leaving)
01:10:37  * kenansul_joined
01:12:02  * thlorenzjoined
01:14:16  * kenansulaymanquit (Ping timeout: 264 seconds)
01:16:33  * esundahljoined
01:16:37  * esundahlquit (Read error: Connection reset by peer)
01:17:07  * esundahljoined
01:20:08  * thlorenzquit (Ping timeout: 240 seconds)
01:29:35  <levelbot>[npm] bjorling-level-storage@0.5.0 <http://npm.im/bjorling-level-storage>: leveldb storage for Bjorling (@bmavity)
01:30:47  * dguttmanquit (Quit: dguttman)
01:34:05  * julianduquejoined
01:37:23  * fallsemojoined
01:44:00  * thlorenzjoined
01:44:28  * ralphtheninjaquit (Ping timeout: 240 seconds)
01:50:02  * fallsemoquit (Ping timeout: 264 seconds)
01:58:09  * alexijoined
02:14:54  * alexiquit (Remote host closed the connection)
02:30:11  * kenansul_quit (Quit: ≈ and thus my mac took a subtle yet profound nap ≈)
02:32:00  * kenansulaymanjoined
02:41:28  * jmartins_quit (Quit: Konversation terminated!)
02:44:59  * mikealjoined
02:49:52  * thlorenz_joined
02:54:35  * thlorenz_quit (Ping timeout: 272 seconds)
03:46:30  * timoxleyquit (Remote host closed the connection)
03:47:05  * timoxleyjoined
03:51:40  * timoxleyquit (Ping timeout: 265 seconds)
04:07:17  * timoxleyjoined
04:09:18  * timoxleyquit (Remote host closed the connection)
04:09:53  * timoxleyjoined
04:14:08  * timoxleyquit (Ping timeout: 240 seconds)
04:40:26  * timoxleyjoined
04:45:00  * timoxleyquit (Ping timeout: 245 seconds)
04:47:28  <Raynos>o/
04:47:33  <Raynos>julianduque: O/
04:48:18  <julianduque>o/
04:49:34  <Raynos>julianduque: i'm looking at https://github.com/julianduque/level-geo
04:49:40  <Raynos>the index is an in memory rtree
04:49:45  <Raynos>so it looks like this module is memory bound
04:50:15  <julianduque>Raynos: yes, it is, haven't found a good way to use leveldb as index
04:50:41  * thlorenz_joined
04:50:41  <Raynos>julianduque: one thing to do is to have many indexes, one per spacial bucket
04:51:09  <Raynos>then there is an upper bound to the memory
04:52:39  <Raynos>the other thing is you could store the rtree in leveldb & implement bbox as a range query :D
04:52:42  <Raynos>good luck (tm)
04:54:23  * DTrejoquit (Remote host closed the connection)
04:54:50  * DTrejojoined
04:55:39  * thlorenz_quit (Ping timeout: 272 seconds)
04:56:20  * alexijoined
04:59:04  * DTrejoquit (Ping timeout: 240 seconds)
05:00:32  <julianduque>Raynos: :)
05:01:33  <Raynos>maybe i should just do it
05:01:35  <Raynos>how hard can it be
05:01:39  <Raynos>it will be nice when its done
05:01:57  <alexi>Hi all, I've got interesting situation here.
05:02:10  <julianduque>Raynos: that would be better :p
05:02:12  <alexi>I'm using leveldown + levelup
05:02:25  <alexi>(level package)
05:02:38  <alexi>and hosting it on rackspace vm, debian 6
05:03:05  <alexi>It was running for couple hours there with very mild load
05:03:27  <alexi>like < 500 writes in total
05:03:46  <alexi>and I lost some data
05:04:23  <alexi>I mean I wrote that data and I saw it in the browser for some time but then it was gone for the db file
05:04:31  * DTrejojoined
05:05:02  <alexi>I restarted my server (node) and played with it a bit ore for another 20 minutes
05:05:39  <alexi>and again after I restarted the server, my state was reverted to the something it was 2 hours before
05:06:24  <alexi>I can't reproduce it at will, but I'm going to try to use sync:true flag
05:06:38  <alexi>And thought maybe you can give me other suggestions
05:06:43  <alexi>and it's something obvious
05:06:57  <brycebaril>alexi: that would be my first suggestion, but I've not seen or heard of something like that before...
05:07:18  <alexi>I created those data file with levelup 0.16 and then updated it to 0.17
05:07:52  <brycebaril>oh? Hmmm, I wonder if that is the version that changed the file suffix. rvagg ^^ alexi is dealing with a lost data issue
05:08:10  <alexi>I tested it for couple weeks before on my laptop (air/osx) and everything was ok
05:08:55  * DTrejoquit (Ping timeout: 246 seconds)
05:09:01  <alexi>but it's not like files are corrupted or anything
05:09:04  <brycebaril>what do you see when you do ls -l in your database folder?
05:09:57  <alexi>https://gist.github.com/alexindigo/6986783
05:10:15  <rvagg>there was a leveldb upgrade in there I think, from 1.11 to 1.14, but there really shouldn't be any data loss
05:10:19  <alexi>btw, I manage two data files within same node process
05:10:24  <rvagg>and sync:true is unlikely to actually make much difference
05:11:22  <alexi>and it's funny that it ended with some midway state
05:11:50  <alexi>I started server clean and added bunch of data and right now just see only first 5%
05:12:06  <alexi>not like it was lost completely
05:12:36  <alexi>I installed and used 'lev' only after I saw data loss
05:12:40  * DTrejojoined
05:13:31  <alexi>btw, it's not sensitive data yet, so I'm fine to send you my files and source code
05:15:19  <brycebaril>I take it you didn't see your data in lev?
05:16:27  <alexi>I saw same amount of data as I saw it on the web
05:18:32  * DTrejoquit (Read error: Connection reset by peer)
05:18:58  * DTrejojoined
05:19:20  * DTrejoquit (Read error: Connection reset by peer)
05:20:12  * julianduquequit (Quit: leaving)
05:20:12  <brycebaril>alexi: I would try creating a database & populating it with a few hundred records with 0.16, stopping, seeing they are all there, then updating to 0.17 and looking, to see if you can make a simple repro case
05:20:43  <alexi>I'll try, thanx
05:22:29  * esundahlquit (Remote host closed the connection)
05:41:08  * timoxleyjoined
05:45:28  * timoxleyquit (Ping timeout: 240 seconds)
05:51:07  * thlorenz_joined
05:53:32  * esundahljoined
05:55:26  * thlorenz_quit (Ping timeout: 240 seconds)
06:01:50  * esundahlquit (Ping timeout: 240 seconds)
06:10:29  * timoxleyjoined
06:23:28  * thlorenzquit (Remote host closed the connection)
06:28:22  * esundahljoined
06:33:15  * esundahlquit (Ping timeout: 260 seconds)
06:51:32  * thlorenzjoined
06:55:50  * thlorenzquit (Ping timeout: 245 seconds)
06:57:46  * jcrugzzquit (Ping timeout: 246 seconds)
07:06:35  <alexi>brycebaril: Suggested test fail, means data was written with no issues.
07:07:01  <alexi>brycebaril: But I was able to reproduce data loss on my laptop
07:07:59  <alexi>brycebaril: I write some data from web interface, I get confirmation after db.put pull callback executed with no err.
07:08:39  <alexi>brycebaril: then I stop my server, start server again and last added record is not there.
07:08:56  <alexi>brycebaril: server starts and connects to the db, with no errors
07:09:42  <alexi>brycebaril: but when I tried to connect to it with lev, it fail with "corruption message"
07:10:37  <alexi>brycebaril: https://gist.github.com/alexindigo/6986783
07:27:23  * jcrugzzjoined
07:32:59  * jcrugzzquit (Ping timeout: 260 seconds)
07:51:53  * thlorenzjoined
07:52:08  * eugenewarechanged nick to zz_eugeneware
07:56:14  * thlorenzquit (Ping timeout: 240 seconds)
08:25:09  * thlorenzjoined
08:30:25  * thlorenzquit (Ping timeout: 245 seconds)
08:51:44  <rvagg>alexi, hij1nx: lev needs to be updated to 0.17+ to get the latest leveldb, it's not going to be able to read .ldb files and will be looking for .sst files only, perhaps you can put in a PR for it?
08:51:54  <rvagg>that'll be what those errors are about from lev
08:52:04  <rvagg>not actual corruption
08:52:28  <alexi>rvagg: I see, thanx
08:52:43  <alexi>Any ideas, why data can be missing?
08:52:45  <rvagg>so I'd suggest you're most likely to have an issue somewhere in your program that's letting the callback bubble back up before it's actually coming out of levelup
08:53:10  <rvagg>perhaps you could log the data that's written as it comes directly out of levelup, just to see exactly what's going on
08:56:09  <alexi>You mean like read stream that will output new stuff?
08:56:19  <alexi>Btw, this the code that is saving to db
08:56:20  <alexi>https://gist.github.com/alexindigo/6988693
08:57:12  <alexi>I think I'll have local data only if callback has no errors
08:57:39  <rvagg>hm, and what exactly is _db? is it a plain levelup instance or is it modified with extensions?
09:01:37  <alexi>level package, I updated gist with _db code
09:02:58  <alexi>this one, will be much easier – https://github.com/alexindigo/shiro/blob/master/lib/chat.js#L47
09:04:25  <alexi>I started to recall, last year, I had similar problem with levelup and I bugged you about it. And problem was I didn't close connection when I switched from one db to another, or something like that.
09:04:54  <alexi>But then you updated levelup so it won't be a problem, I believe
09:09:35  <alexi>Oh
09:09:58  <alexi>So 0.17 writes and reads from .ldb files and 0.16 from .sst files
09:10:16  <alexi>and there is probably index that points to data files
09:10:38  <alexi>and since it was created in 0.16 it points to .sst files which have only old data
09:10:48  <alexi>does it sound about right?
09:25:31  <rvagg>so, 0.17 (leveldb 1.14) should be ok with both .sst from old versions and .ldb from new
09:25:52  <rvagg>there shouldn't be an issue with it reading old directories, you'll just start to get a conversion from .sst to .ldb over time
09:26:26  <rvagg>if that worries you at all you could switch out to level-hyper which still uses .sst but is at 0.17 and will generally perform better anyway
09:26:48  <rvagg>at some point rescrv will catch up and switch to .ldb as well I imagine
09:27:36  * thlorenzjoined
09:32:05  * thlorenzquit (Ping timeout: 245 seconds)
09:32:50  * wolfeida_joined
09:34:07  <alexi>Not really worried :) I'm trying to understand where my data go :)
09:35:55  <rvagg>yeah, that's an odd problem
09:36:14  <rvagg>still.. how about you stick a console.log in the callback whenever save() finishes just so you can actually SEE it on the server side going in
09:36:27  <rvagg>if the stuff you see on the console doesn't end up sticking around in the db then that's a worry
09:36:35  <rvagg>unless you have something else messing with it, like level-ttl
09:37:25  <alexi>Sure thing, and just to clarify it is ok to connect to two leveldb files from the same node process, right?
09:37:37  <rvagg>yep, as many as you think is sensible
09:37:49  <rvagg>keeping in mind that there is memory to be managed
09:37:54  <rvagg>alexi: http://r.va.gg/2013/10/should-i-use-a-single-leveldb-or-many-to-hold-my-data.html
09:38:30  <rvagg>but as far as the internals go, there is no overlap in any of the level* packages that prevent multiple leveldb instances in the same process
09:38:34  * wolfeidauquit (Read error: Connection reset by peer)
09:38:34  * levelbotquit (Ping timeout: 272 seconds)
09:38:35  <rvagg>they are kept separate
09:39:16  <alexi>It's funny that the main reason I wanted to split into two files, that i have data I really care about and which is updated not as often (game state) and data which I don't really care about and updated much more often (game chat) :)
09:41:35  <rvagg>mmm, you may also find that you can extend levelup in different ways for both of those types of data
09:41:52  <rvagg>and then you can use different replication mechanisms if it comes to that too
09:42:02  <rvagg>.. or you could be using sublevel to achieve a similar result
09:42:25  <alexi>I mean, for me it's file corruption possibility :) so I wanted separate files
09:42:31  <alexi>so I added console.log
09:42:44  * ralphtheninjajoined
09:42:55  <alexi>and I see stuff in the console and after I restart node process data is gone
09:43:30  <alexi>my new save function https://gist.github.com/alexindigo/6989182
09:44:41  <alexi>updated gist with console.log output
09:49:16  <rvagg>ok, and it's not possible that `options.storage` is changing between restarts?
09:49:44  <rvagg>and you're sure you don't have a filesystem that is temporary or non-persistent somehow?
09:50:12  <rvagg>AND, lastly, double-check that you only have one Node process running this; not that it should allow multiple processes to access the dir
09:51:01  <alexi>options.storage is hard coded: new Chat({env: envar, storage: path.join(dataPath, 'chat.db')});
09:51:56  <alexi>filesystem is standard osx
09:52:16  <alexi>just single node process
09:52:47  * thlorenzjoined
09:52:54  <alexi>I don't do explicit close() on exit though
09:53:12  <rvagg>that shouldn't matter..
09:54:59  <alexi>is there some kind of debug flag, I can turn on to see what's it's actually writing?
09:56:51  <rvagg>not really
09:57:11  * thlorenzquit (Ping timeout: 260 seconds)
10:03:35  <alexi>This is tar archive of the db, if you're interested – http://ia.gs/RwBg
10:06:08  <alexi>And I'm off for today it's 3am :) Thank you for helping me
10:07:25  <rvagg>alexi: before you go
10:07:30  <alexi>yep
10:07:38  <rvagg>this db, what's something in there that you expect to be there but is not?
10:07:43  <rvagg>I'm poking around with lev now
10:07:50  <rvagg>plenty of messages
10:08:22  <alexi>I'm adding new messages like the one in this gist – https://gist.github.com/alexindigo/6989182
10:08:39  <alexi>but when I restart node it's not there
10:08:55  <alexi>oh another idea
10:11:47  <alexi>db clearly thinks data is there – https://gist.github.com/alexindigo/6989450
10:13:56  <rvagg>there's plenty of messages in there
10:14:06  <rvagg>is there a chance that you're not referencing the keys that you expect
10:14:48  <rvagg>so, to inspect it yourself for now, you can go in to chat.db and rename all .ldb to .sst and use lev
10:14:52  <rvagg>that's what I'm doing
10:15:04  <alexi>1 sec
10:15:06  <rvagg>alternatively you could go in to lev and force an upgrade to levelup 0.17, it should still work
10:18:18  <alexi>You're right, I feel bad. Lev sees data there, Let me try run the whole thing with renamed files
10:20:49  <alexi>Ok, with chat messages I do truncate results, but I saw same problem with game answers on linux box where I don't truncate and lev showed only small chunk of data I saw on the page.
10:21:02  <alexi>I'll come back when I have something reproducable
10:21:08  <alexi>thanx again
10:28:12  * thlorenzjoined
10:32:51  * thlorenzquit (Ping timeout: 272 seconds)
10:44:16  * zz_eugenewarechanged nick to eugeneware
10:53:10  * thlorenzjoined
10:58:11  * thlorenzquit (Ping timeout: 272 seconds)
11:11:42  * fallsemojoined
11:14:57  * insertcoffeejoined
11:23:58  * wolfeida_changed nick to wolfeidau
11:28:15  * fallsemoquit (Ping timeout: 240 seconds)
11:51:25  * Acconutjoined
11:53:34  * thlorenzjoined
11:58:21  * thlorenzquit (Ping timeout: 272 seconds)
12:00:11  * fallsemojoined
12:05:17  * fallsemoquit (Ping timeout: 268 seconds)
12:08:19  * fallsemojoined
12:17:00  <rescrv>rvagg: I don't know that I'll be adding *.ldb. I think sst is a better extension, and think it's silly to work around a Windows problem.
12:17:13  * Acconutquit (Quit: Acconut)
12:25:08  <rvagg>rescrv: I agree, can you add logic to at least take them into account so that stores created with google's leveldb can be read by yours?
12:30:14  * fallsemoquit (Ping timeout: 240 seconds)
12:53:57  * thlorenzjoined
12:58:20  * thlorenzquit (Ping timeout: 245 seconds)
13:00:18  * fallsemojoined
13:04:56  * fallsemoquit (Ping timeout: 246 seconds)
13:14:52  * fallsemojoined
13:16:05  * eugenewarechanged nick to zz_eugeneware
13:16:50  * fallsemoquit (Client Quit)
13:16:53  * thlorenzjoined
13:29:31  * thlorenzquit (Remote host closed the connection)
13:30:07  * thlorenzjoined
13:37:40  * thlorenz_joined
13:40:25  * thlorenz_quit (Remote host closed the connection)
13:41:34  * thloren__joined
13:41:57  * thlorenzquit (Ping timeout: 272 seconds)
13:44:11  * fallsemojoined
13:54:18  * tmcwjoined
14:00:13  * thloren__quit (Remote host closed the connection)
14:01:16  <rescrv>rvagg: I may have to do that. I don't want to though. The whole point of not adding the dual-casing is to improve robustness by not having state blow-up for all the different possibilities.
14:10:39  <rescrv>they've already had two bugs upstream from it
14:17:55  * dguttmanjoined
14:18:55  * levelbotjoined
14:18:55  <levelbot>[npm] lev@1.2.0-1 <http://npm.im/lev>: commandline and REPL access for leveldb (@hij1nx, @juliangruber)
14:29:01  * jjmalinajoined
14:31:34  * jmartinsjoined
14:39:53  * esundahljoined
14:41:32  * marshaliumjoined
14:42:08  * marshaliumpart
14:44:27  * mikealquit (Quit: Leaving.)
14:45:26  * kenansulaymanquit (Quit: ≈ and thus my mac took a subtle yet profound nap ≈)
14:54:51  * thlorenzjoined
14:59:02  * thlorenzquit (Ping timeout: 240 seconds)
15:04:26  * jmartinsquit (Ping timeout: 264 seconds)
15:06:18  * mikealjoined
15:08:56  * jerrysvjoined
15:23:13  * timoxleyquit (Remote host closed the connection)
15:31:13  * ednapiranhajoined
15:39:16  * alexiquit (Remote host closed the connection)
15:47:25  * jmartinsjoined
15:55:11  * thlorenzjoined
16:00:14  * thlorenzquit (Ping timeout: 268 seconds)
16:04:34  * jcrugzzjoined
16:05:21  * insertcoffeequit (Read error: Operation timed out)
16:09:35  * jerrysvquit (Ping timeout: 260 seconds)
16:10:37  * mikealquit (Quit: Leaving.)
16:14:12  * jcrugzzquit (Remote host closed the connection)
16:16:16  <levelbot>[npm] shiro@0.1.1 <http://npm.im/shiro>: シロ – white, also part of shirofukurou (シロフクロウ) snowy owl. Online questions game management system. (@alexindigo)
16:19:49  * jerrysvjoined
16:34:27  * timoxleyjoined
16:38:46  * timoxleyquit (Ping timeout: 246 seconds)
16:39:47  * dguttmanquit (Quit: dguttman)
16:55:37  * thlorenzjoined
16:57:23  * jxsonjoined
17:00:27  * thlorenzquit (Ping timeout: 272 seconds)
17:02:39  * mikealjoined
17:03:26  * dominictarrjoined
17:08:01  * jmartinsquit (Quit: Konversation terminated!)
17:17:44  * dominictarrquit (Quit: dominictarr)
17:32:50  * julianduquejoined
17:32:57  * paulfryzeljoined
17:33:05  * kenansulaymanjoined
17:45:19  * dominictarrjoined
17:50:27  * alexijoined
17:51:10  * dguttmanjoined
17:51:33  * nnnnathannjoined
17:56:05  * thlorenzjoined
17:56:07  * dguttmanquit (Ping timeout: 246 seconds)
18:01:15  * thlorenzquit (Ping timeout: 272 seconds)
18:02:16  <levelbot>[npm] shiro@0.1.1 <http://npm.im/shiro>: シロ – white, also part of shirofukurou (シロフクロウ) snowy owl. Online questions game management system. (@alexindigo)
18:04:41  * dguttmanjoined
18:08:02  * nnnnathannquit (Remote host closed the connection)
18:51:56  * jcrugzzjoined
19:05:18  * jcrugzzquit (Ping timeout: 252 seconds)
19:05:26  * dominictarrquit (Quit: dominictarr)
19:07:19  * esundahlquit (Remote host closed the connection)
19:07:23  * jcrugzzjoined
19:11:07  * esundahljoined
19:11:46  * thlorenzjoined
19:24:33  * tmcwquit (Remote host closed the connection)
19:38:56  * topek_joined
19:39:36  * tmcwjoined
19:48:03  * fallsemoquit (Quit: Leaving.)
19:49:28  * Acconutjoined
19:50:09  * Acconutquit (Client Quit)
19:52:27  * jxsonquit (Remote host closed the connection)
19:52:55  * jxsonjoined
19:54:45  * jxson_joined
19:56:54  * thlorenz_joined
19:57:08  * jxsonquit (Read error: Connection reset by peer)
20:01:22  * thlorenz_quit (Ping timeout: 256 seconds)
20:06:48  * dominictarrjoined
20:11:56  * fallsemojoined
20:15:48  * timoxleyjoined
20:20:30  * alexiquit (Remote host closed the connection)
20:22:32  * jcrugzz_joined
20:25:10  * jcrugzzquit (Ping timeout: 256 seconds)
20:26:02  * Acconutjoined
20:27:15  * jcrugzz_changed nick to jcrugzz
20:28:00  * Acconutquit (Client Quit)
20:38:03  * timoxleyquit (Remote host closed the connection)
20:39:46  <levelbot>[npm] zeos-level-finder@0.0.1 <http://npm.im/zeos-level-finder>: Node module for manage level. (@fmathey)
20:52:38  * timoxleyjoined
20:57:18  * thlorenz_joined
21:02:07  * thlorenz_quit (Ping timeout: 272 seconds)
21:03:38  * jerrysvquit (Ping timeout: 268 seconds)
21:03:48  * jerrysv__joined
21:03:59  * jerrysv__changed nick to jerrysv
21:11:32  * alexijoined
21:29:50  * thlorenz_joined
21:31:08  * julianduquequit (Ping timeout: 240 seconds)
21:31:34  * ednapiranhaquit (Remote host closed the connection)
21:33:25  * thlorenzquit (Ping timeout: 272 seconds)
21:43:45  <levelbot>[npm] zeos-level-finder@0.0.2 <http://npm.im/zeos-level-finder>: Node module for manage level. (@fmathey)
21:51:41  * topek_quit (Remote host closed the connection)
21:57:43  * thlorenzjoined
22:02:03  * thlorenzquit (Ping timeout: 248 seconds)
22:13:49  <levelbot>[npm] nitrogen@0.1.45 <http://npm.im/nitrogen>: Nitrogen is a platform for building connected devices. Nitrogen provides the authentication, authorization, and real time message passing framework so that you can focus on your device and application. All with a consistent development platform that leverages the ubiquity of Javascript. (@tpark)
22:14:40  * esundahlquit (Remote host closed the connection)
22:16:02  * esundahljoined
22:17:34  * tmcwquit (Remote host closed the connection)
22:57:29  * esundahlquit (Remote host closed the connection)
22:57:55  * esundahljoined
22:58:10  * thlorenzjoined
23:00:51  * esundahlquit (Read error: Connection reset by peer)
23:01:05  * esundahljoined
23:03:05  * thlorenzquit (Ping timeout: 272 seconds)
23:05:57  * julianduquejoined
23:11:07  * fallsemoquit (Quit: Leaving.)
23:12:59  * julianduquequit (Read error: Connection reset by peer)
23:13:06  * thlorenz_quit (Remote host closed the connection)
23:22:09  * jjmalinaquit (Quit: Leaving.)
23:44:10  * thlorenzjoined
23:46:16  <ogd>brycebaril: w00t integrated buff into dat https://github.com/maxogden/dat/blob/master/test/test.js#L57, also the csv test parses csv rows into buff
23:50:33  <brycebaril>ogd: awesome!
23:52:30  * thlorenzquit (Ping timeout: 245 seconds)
23:54:06  * esundahlquit (Remote host closed the connection)
23:54:33  * esundahljoined
23:58:48  * esundahlquit (Ping timeout: 240 seconds)
23:59:16  <levelbot>[npm] alldata-storage-leveldb@0.1.0 <http://npm.im/alldata-storage-leveldb>: AllData LevelDB-backed storage (@tristanls)