00:03:39  <jerrysv>rvagg: yeah, was going to do some updates tonight - silly hobbies
00:05:49  * jjmalinaquit (Ping timeout: 252 seconds)
00:08:45  * dguttmanquit (Quit: dguttman)
00:14:32  * ednapiranhaquit (Quit: Leaving...)
00:15:27  * thlorenzjoined
00:15:43  * thlorenzquit (Remote host closed the connection)
00:15:59  * thlorenzjoined
00:28:50  * paulfryzelquit (Read error: Connection reset by peer)
00:29:18  * paulfryzeljoined
00:29:27  * ryan_ramagequit (Quit: ryan_ramage)
00:33:14  * jcrugzzjoined
00:36:48  * kenansulaymanquit (Ping timeout: 246 seconds)
00:37:50  * kenansulaymanjoined
00:37:58  * paulfryzelquit (Read error: Connection reset by peer)
00:38:29  * paulfryzeljoined
00:38:57  <rescrv>rvagg, kenansulayman: what would you recommend for the "set" data type in JS? string, int, float, list, map should be easy, but JS doesn't have sets
00:40:02  <brycebaril>rescrv: probably just the same as map, though it will have Sets very soon, in fact you can enable them in node at the command-line
00:40:55  <kenansulayman>Isn't set best described by an object?
00:41:00  <rescrv>brycebaril: we do type introspection of sorts. you pass {attr: "some string"}, and we tell hyperdex that attr is a string. It makes writing bindings easier
00:41:15  <rescrv>so each type needs to be distinctive or I have to write some hacky code
00:41:30  <brycebaril>rescrv: http://dailyjs.com/2012/10/15/preparing-for-esnext/ though you can't generally rely on users using these flags yet
00:41:49  <kenansulayman>In object each value must be unique and is identified by its key; so it's actually the matching type afaik
00:41:50  <brycebaril>rescrv i see
00:41:56  <kenansulayman>s/afaik/imho/
00:43:39  <brycebaril>rescrv: I'd most likely go through npm and find the best choice, ideally one that uses native Sets if available https://npmjs.org/search?q=set
00:44:26  <kenansulayman>Is there a misunderstanding here? rescrv, what are up to?
00:44:48  * paulfryzelquit (Remote host closed the connection)
00:47:30  <rescrv>kenansulayman: I'm not sure. I think brycebaril suggesting sets from npm might be best. Essentially a HyperDex scripting language binding is just type conversion. All the fancy stuff is in the HyperDex client lib and should not be duplicated. Things like, "Can someone do setContains("x") on a set of integers". There's one place we check this and it's correct. I don't want to have to validate this in
00:47:32  <rescrv>the scripting language and again in the hyperdex client library.
00:48:03  <rescrv>The way I do this now is to just convert whatever the user gives into its appropriate HyperDex representation. So "foo" becomes a hyperdex string. 5 becomes a hyperdex int. [1,2,3
00:48:07  <rescrv>] is a list of strings
00:48:25  <rescrv>I'll then throw the appropriate error by interpreting the failure of the C call.
00:49:07  <rescrv>I'm just figuring out how to decide the question, "Is this thing the user is passing in a set?" If I can unambiguously decide this, I can always encode it as a set, and let the HyeprDex library decide if that's acceptable.
00:50:35  <kenansulayman>If the user is able to input a set and you want to detect that; what would you expect it to be? I think the only "comparable" instance of a "set" would be a plain object
00:51:20  <rvagg>rescrv: if you really wanted to you could take a class-based approach and if the user wants to pass in a particular type then they need to pass it in as one of your types
00:51:27  <rvagg>rescrv: new HyperSet({ whatever })
00:51:34  <kenansulayman>indeed
00:51:58  <rvagg>accept sloppy input and convert as you see appropriate but provide the option for them to be strict with types
00:52:21  <rescrv>rvagg kenansulayman: I think what I'm going to do is go read up on all this that you guys have sent, and then come back when I have some functioning code to run by you.
00:52:50  <kenansulayman>Sure, whatever it takes :)
00:53:01  <brycebaril>rescrv: yes, what rvagg says for the api-layer. You pretty much won't be able to infer a 'set' vs a 'hash' unless the user specifically tells you, and the best way for that would be to expose a set constructor in the api
00:53:35  <rescrv>brycebaril: that's all I'm looking for. I'll probably go that route then.
00:57:07  * esundahl_quit (Remote host closed the connection)
00:57:16  * kenansulaymanquit (Ping timeout: 245 seconds)
00:57:34  * esundahljoined
00:59:54  * dguttmanjoined
01:01:19  * kenansulaymanjoined
01:02:24  * esundahlquit (Ping timeout: 272 seconds)
01:28:07  * kenansulaymanquit (Quit: ≈ and thus my mac took a subtle yet profound nap ≈)
01:30:30  * daleharveyjoined
01:30:30  * jxsonquit (Remote host closed the connection)
01:30:37  <rvagg>rescrv: can you recall reasons this might happen: (dummy_versions_.next_ == &dummy_versions_), function ~VersionSet, file ../deps/leveldb/leveldb-1.14.0/db/version_set.cc, line 803
01:30:46  <rvagg>I remember coming across this a few times a while ago but I haven't seen it for a while
01:30:57  <rvagg>rescrv: daleharvey is running in to it now with a recent upgrade and I can't explain it
01:30:58  * jxsonjoined
01:31:42  <daleharvey>ill give 10.8 vs 10.9 a shot
01:35:25  * jxsonquit (Ping timeout: 246 seconds)
01:35:52  <rescrv>rvagg: is this an assert fail?
01:36:01  * jxsonjoined
01:36:07  <rvagg>yeah, internal leveldb assertion
01:36:27  <rescrv>rvagg: stock level? I think so, but double checking
01:37:20  <rescrv>so what's going on is you're deleting the database while a snapshot to it still exists.
01:37:23  <rvagg>yeah, stock, unchanged
01:37:49  <rvagg>ah, hm... we're only making snapshots via iterators so we must not be freeing those
01:37:55  <rescrv>create db, create snapshot, delete db, see failure
01:37:57  <rvagg>we should be.. ugh
01:38:20  <rvagg>I have a whole lot of code dedicated to dealing with this, which is I guess why we haven't seen this come up again
01:38:26  <rescrv>the way I solved this in HyperDex was to make everything that wrapped a snapshot or iterator keep a ref-counted pointer to the db
01:38:56  <daleharvey>Its fairly likely I can hit something like that, the code that this is hitting is fairly quircky, a bunch of it is slated to get removed
01:38:57  <rescrv>that way we could just delete stof in any order and it'd take care of itself
01:39:46  <daleharvey>but I have a database registry, so every open is getting wrapped in an open write to the registry database, and both of these are being created / deleted constantly (its in a test harness)
01:40:06  <rescrv>daleharvey: then make sure that you don't delete without deleting the iterators too
01:42:40  * tarrudaquit (Read error: Connection reset by peer)
01:42:42  * thlorenzquit (Remote host closed the connection)
01:43:08  <rescrv>rvagg: if you can, I'd solve this at the levelX layer as that seems most appropriate
01:43:59  <rvagg>rescrv: yeah, we have code that keeps references to each iterator so that prior to a proper close() we can go ahead and end each of the currently open ones
01:44:22  <rvagg>I guess that's not working quite right... tho I have some tests for this situation
01:52:24  * thlorenzjoined
01:52:47  * jerrysvquit (Remote host closed the connection)
02:00:26  * kevinswiberjoined
02:03:45  * DTrejoquit (Remote host closed the connection)
02:03:54  * stagasjoined
02:05:19  * DTrejojoined
02:10:07  * DTrejoquit (Remote host closed the connection)
02:11:06  * quimquit
02:12:24  * jcrugzzquit (Ping timeout: 240 seconds)
02:13:16  * DTrejojoined
02:13:18  * mikealquit (Quit: Leaving.)
02:14:42  * jxsonquit (Remote host closed the connection)
02:15:10  * jxsonjoined
02:16:33  * paulfryzeljoined
02:17:26  * DTrejoquit (Remote host closed the connection)
02:20:10  * jxsonquit (Ping timeout: 265 seconds)
02:20:58  * paulfryzelquit (Ping timeout: 245 seconds)
02:22:50  * thlorenzquit (Remote host closed the connection)
02:24:18  * wolfeidauquit (Ping timeout: 245 seconds)
02:25:34  * esundahljoined
02:26:21  * thlorenz_joined
02:26:39  * kevinswiberquit (Remote host closed the connection)
02:31:39  * jxsonjoined
02:42:42  <daleharvey>rvagg: is there an open issue for this?
02:44:43  * jxsonquit (Ping timeout: 245 seconds)
02:46:39  <rvagg>daleharvey: no, hang on and I'll see if I can find the old one
02:50:11  <rvagg>daleharvey: if this is causing problems then perhaps you could try switching to level-hyper and see if it makes a difference at all? you should get a speed increase at least
02:51:41  <ogd>heh https://twitter.com/HackerNewsOnion/status/405165602517446659
02:53:01  <daleharvey>rvagg: will do, ill give a shot at bisecting a well since its only started happening recently
02:53:12  <rvagg>excellent
02:53:27  <rvagg>ogd: haha!
02:57:21  <rescrv>rvagg: iterator vs. snapshot. An iterator will make an implicit snapshot.
02:57:28  <rescrv>it may make a difference to you
02:57:37  <rvagg>rescrv: yeah, we haven't exposed the snapshot api yet at all so it'll be all about iterators
02:57:51  <rvagg>it never got done and there just hasn't been a demand for it at all
03:01:24  * wolfeidaujoined
03:15:36  * tmcwquit (Read error: Connection reset by peer)
03:16:09  * jxsonjoined
03:17:18  * paulfryzeljoined
03:18:26  * tmcwjoined
03:20:02  * jxsonquit (Read error: Connection reset by peer)
03:20:31  * jxsonjoined
03:21:27  * jxsonquit (Read error: Connection reset by peer)
03:21:48  * paulfryzelquit (Ping timeout: 245 seconds)
03:57:08  * brycebarilquit (Ping timeout: 240 seconds)
04:04:05  * mikealjoined
04:09:48  * thlorenz_quit (Remote host closed the connection)
04:10:26  * thlorenz_joined
04:14:40  * thlorenz_quit (Ping timeout: 246 seconds)
04:18:02  * paulfryzeljoined
04:22:13  * paulfryzelquit (Ping timeout: 245 seconds)
04:24:12  * wolfeidauquit (Remote host closed the connection)
04:25:48  * jxsonjoined
04:29:25  * mikealquit (Quit: Leaving.)
04:29:47  * brycebariljoined
04:34:11  * dominictarr_joined
04:44:36  * dominictarr_quit (Quit: Leaving)
04:44:45  * dominictarr_joined
04:53:34  * dominictarr_quit (Ping timeout: 272 seconds)
05:11:01  * thlorenzjoined
05:14:01  * dguttmanquit (Quit: dguttman)
05:18:48  * paulfryzeljoined
05:19:29  * thlorenzquit (Ping timeout: 265 seconds)
05:23:03  * paulfryzelquit (Ping timeout: 245 seconds)
05:29:08  <chapel>want some advice on how to handle multiple writes at the same time, in a job queue like system
05:31:39  <chapel>preventing overwriting the same key even if a write with the same key is called multiple times in the same tick
05:33:28  <stagas>chapel: https://github.com/stagas/level-atomic
05:33:34  * mikealjoined
05:35:32  * mikealquit (Client Quit)
05:36:44  <chapel>thanks
05:36:53  * esundahlquit (Remote host closed the connection)
05:37:30  * esundahljoined
05:39:15  * dominictarr_joined
05:42:03  * dguttmanjoined
05:42:28  * esundahlquit (Ping timeout: 264 seconds)
05:44:29  * wolfeidaujoined
05:46:33  <rvagg>chapel: also https://github.com/mikeal/level-mutex
05:46:49  * mikealjoined
05:46:58  <chapel>yeah found that as well
05:47:03  <chapel>its for a coworker
05:51:03  * mikealquit (Ping timeout: 246 seconds)
05:58:34  * mikealjoined
06:00:24  * jxsonquit (Remote host closed the connection)
06:00:52  * jxsonjoined
06:05:11  * jxsonquit (Ping timeout: 240 seconds)
06:05:18  <levelbot>[npm] dynalite@0.2.1 <http://npm.im/dynalite>: A mock implementation of Amazon's DynamoDB built on LevelDB (@hichaelmart)
06:16:07  * thlorenzjoined
06:18:29  * wolfeidauquit (Remote host closed the connection)
06:19:35  * paulfryzeljoined
06:23:53  * paulfryzelquit (Ping timeout: 245 seconds)
06:26:43  * dguttmanquit (Quit: dguttman)
06:30:03  * thlorenzquit (Ping timeout: 265 seconds)
06:32:47  * jcrugzzjoined
06:33:23  * esundahljoined
06:37:05  * jcrugzzquit (Ping timeout: 245 seconds)
06:38:16  * esundahlquit (Ping timeout: 265 seconds)
06:38:29  * jcrugzzjoined
06:55:09  * stagasquit (Ping timeout: 272 seconds)
07:08:42  * thlorenzjoined
07:20:21  * paulfryzeljoined
07:21:55  * thlorenzquit (Ping timeout: 246 seconds)
07:24:43  * paulfryzelquit (Ping timeout: 245 seconds)
07:25:55  * jcrugzzquit (Ping timeout: 272 seconds)
07:34:11  * stagasjoined
07:56:19  * jcrugzzjoined
08:03:00  * aba_joined
08:03:49  * stagasquit (Ping timeout: 272 seconds)
08:15:56  * ramitosquit (Quit: Textual IRC Client: www.textualapp.com)
08:18:32  * thlorenzjoined
08:21:07  * paulfryzeljoined
08:24:07  * brycebarilquit (Ping timeout: 265 seconds)
08:25:33  * paulfryzelquit (Ping timeout: 245 seconds)
08:32:11  * thlorenzquit (Ping timeout: 252 seconds)
08:36:15  * jcrugzzquit (Ping timeout: 245 seconds)
08:36:51  * jcrugzzjoined
08:36:51  * dominictarr_quit (Ping timeout: 272 seconds)
08:38:50  <levelbot>[npm] levelup@0.18.2 <http://npm.im/levelup>: Fast & simple storage - a Node.js-style LevelDB wrapper (@rvagg)
08:46:42  <rvagg>^^readable-stream@1.0.x, was 1.1.x which is streams3 but that = breakage for some higher level modules
08:53:46  * aba_quit (Quit: aba_)
08:56:21  * aba_joined
08:56:56  * tarrudajoined
09:06:52  * aba_quit (Quit: aba_)
09:07:35  * mcavage_joined
09:07:36  * mcavagequit (Read error: Connection reset by peer)
09:11:42  * mcollina_quit (Read error: Connection reset by peer)
09:11:51  * mcollinajoined
09:12:36  * kenansulaymanjoined
09:15:06  * frankblizzardjoined
09:17:17  * jcrugzzquit (Ping timeout: 265 seconds)
09:21:53  * paulfryzeljoined
09:25:11  * kenansulaymanquit (Ping timeout: 245 seconds)
09:26:13  * kenansulaymanjoined
09:26:23  * paulfryzelquit (Ping timeout: 245 seconds)
09:28:28  * thlorenzjoined
09:37:51  * quimjoined
09:41:57  * thlorenzquit (Ping timeout: 248 seconds)
09:45:08  * quimquit (Ping timeout: 245 seconds)
09:45:16  * quimjoined
09:52:18  * quimquit (Ping timeout: 240 seconds)
09:52:26  * quimjoined
10:01:39  * quim_joined
10:04:53  * quimquit (Ping timeout: 272 seconds)
10:22:35  * paulfryzeljoined
10:27:13  * paulfryzelquit (Ping timeout: 245 seconds)
10:29:22  <kenansulayman>rescrv What do you think about Facebook Presto?
10:35:50  * quim_quit (Ping timeout: 245 seconds)
10:38:25  * thlorenzjoined
10:39:07  * quimjoined
10:44:01  * insertcoffeejoined
10:52:01  * thlorenzquit (Ping timeout: 272 seconds)
10:54:40  * frankblizzardpart
10:56:42  * wolfeidaujoined
10:58:04  * aba_joined
11:09:16  * aba_quit (Quit: aba_)
11:20:10  * kenansulaymanquit (Quit: ≈♡≈)
11:21:01  * quim_joined
11:23:25  * paulfryzeljoined
11:24:17  * quim__joined
11:24:57  * quimquit (Ping timeout: 272 seconds)
11:26:44  * kenansulaymanjoined
11:27:38  * paulfryzelquit (Ping timeout: 245 seconds)
11:27:45  * quim_quit (Ping timeout: 272 seconds)
11:36:34  * quimjoined
11:38:36  * quim__quit (Ping timeout: 246 seconds)
11:47:55  * thlorenzjoined
11:48:32  * thlorenzquit (Remote host closed the connection)
12:08:04  * tarrudaquit (Remote host closed the connection)
12:11:30  * dominictarr_joined
12:11:54  <dominictarr_>rvagg, hey, I'm setting up my own rpi + tablet + bluetooth kb thing
12:12:20  <dominictarr_>and also, I found a solution to the slippery screen not being in a good position problem
12:16:07  * thlorenzjoined
12:19:49  * thlorenz_joined
12:24:11  * paulfryzeljoined
12:28:28  * paulfryzelquit (Ping timeout: 245 seconds)
12:28:51  <rescrv>kenansulayman: it works for them. I have other ideas in this space, but it's hard to argue with "It works for Facebook"
12:29:35  <kenansulayman>How could BigTable be approached in K/V?
12:29:56  <kenansulayman>BigQuery*
12:30:05  <kenansulayman>Or whatever its called
12:32:27  * esundahljoined
12:33:12  * thlorenz_quit (Ping timeout: 246 seconds)
12:37:05  * esundahlquit (Ping timeout: 245 seconds)
12:37:10  * dominictarr_quit (Quit: Leaving)
12:37:22  * dominictarr_joined
12:48:02  * quimquit (Remote host closed the connection)
12:52:04  <kenansulayman>rescrv
12:53:26  * aba_joined
12:56:16  * tmcwquit
12:59:50  * thlorenz_joined
13:04:45  * kenansulaymanquit (Ping timeout: 246 seconds)
13:07:15  * aba_quit (Quit: aba_)
13:07:16  * kenansulaymanjoined
13:10:38  * aba_joined
13:13:03  * thlorenz_quit (Ping timeout: 245 seconds)