00:00:08  * ircretaryjoined
00:03:55  * st_lukejoined
00:05:00  * ins0mniaquit (Ping timeout: 276 seconds)
00:07:56  * st_lukequit (Ping timeout: 245 seconds)
00:09:38  * ins0mniajoined
00:19:26  * maksimlinjoined
00:21:42  * sorensen_joined
00:21:44  * sorensen_quit (Remote host closed the connection)
00:25:01  <daleharvey>substack: this setup is pretty sweet, one issue is that testling is leaving a browser instance open, checking the source now, that a bug?
00:25:50  * ins0mniaquit (Ping timeout: 240 seconds)
00:27:04  <daleharvey>if I run it with the previous instance open, it hangs
00:29:17  * coderzachquit (Quit: coderzach)
00:33:07  <substack>daleharvey: I don't have a mac so I can't debug that
00:33:15  <substack>happens on mac, not on linux
00:33:38  <daleharvey>ah k, trying out xquartz
00:35:01  * cpettittjoined
00:44:11  <isaacs>ircretary: tell dominictarr Portability
00:44:11  <ircretary>isaacs: I'll be sure to tell dominictarr
00:45:18  * missinglinkquit (Ping timeout: 276 seconds)
00:58:07  * cpettittquit (Quit: cpettitt)
01:08:24  * jergasonjoined
01:08:43  * maksimlinquit (Ping timeout: 260 seconds)
01:16:18  * i_m_cajoined
01:24:00  * thlorenzjoined
01:28:50  * shamaquit (Read error: Connection reset by peer)
01:29:18  * shamajoined
01:30:19  * maksimlinjoined
01:35:51  * i_m_caquit (Ping timeout: 245 seconds)
01:38:48  * calvinfojoined
01:41:36  * jcrugzzjoined
01:50:38  * mikolalysenkoquit (Ping timeout: 264 seconds)
01:56:28  * mikolalysenkojoined
01:57:53  * coderzachjoined
02:11:27  * vitorpachecojoined
02:14:58  * shamaquit (Read error: Connection reset by peer)
02:15:40  * shamajoined
02:16:01  * calvinfoquit (Quit: Leaving.)
02:24:04  * stagasjoined
02:25:10  * maksimlinquit (Quit: ChatZilla [Firefox 23.0/20130803215302])
02:26:42  * shamaquit (Remote host closed the connection)
02:31:54  * calvinfojoined
02:37:13  <thlorenz>Raynos: do you have no shame :P http://i.imgur.com/OUyaMdf.png
02:48:03  <thlorenz>Raynos: I take that back, looks like none of these are actually on github - except maybe 'clientmongo' camouflaged as mongoclient which even my tool can't find ;)
03:20:58  * thlorenzquit (Remote host closed the connection)
03:23:20  * calvinfoquit (Quit: Leaving.)
03:27:50  * vitorpachecoquit (Ping timeout: 240 seconds)
03:33:14  * mikolalysenkoquit (Ping timeout: 264 seconds)
03:34:54  * coderzachquit (Quit: coderzach)
03:38:32  * mikolalysenkojoined
03:50:51  * calvinfojoined
03:52:24  * vitorpachecojoined
03:58:55  * AvianFlujoined
04:04:13  * dguttmanquit (Quit: dguttman)
04:05:30  * jergasonquit (Remote host closed the connection)
04:13:04  * dguttmanjoined
04:16:08  * dguttmanquit (Client Quit)
04:18:03  * jergasonjoined
04:20:11  * coderzachjoined
04:27:35  * gwenbelljoined
04:40:08  * timoxleyjoined
04:43:46  * itprojoined
04:43:46  * itprochanged nick to ITpro
04:49:19  * fotoveritequit (Ping timeout: 240 seconds)
04:49:39  * fotoveritejoined
04:53:31  * gwenbellquit (Quit: Lost terminal)
05:08:53  * jcrugzzquit (Ping timeout: 268 seconds)
05:09:04  * maksimlinjoined
05:34:18  <rvagg>Raynos: ping you here?
05:42:10  * coderzachquit (Quit: coderzach)
05:47:49  * i_m_cajoined
06:00:46  * djcoinjoined
06:01:19  * mikolalysenkoquit (Ping timeout: 260 seconds)
06:08:37  * mikolalysenkojoined
06:13:09  * mikolalysenkoquit (Client Quit)
06:43:55  * AvianFluquit (Remote host closed the connection)
06:53:02  <guybrush>oh this is interesting https://bugzilla.mozilla.org/show_bug.cgi?id=901614
06:54:53  * defunctzombie_zzchanged nick to defunctzombie
07:27:38  * calvinfoquit (Quit: Leaving.)
07:34:44  * jergasonquit (Remote host closed the connection)
07:38:05  <substack>https://github.com/substack/level-assoc#live \o/
07:57:59  * calvinfojoined
07:59:00  * defunctzombiechanged nick to defunctzombie_zz
08:05:26  * calvinfoquit (Ping timeout: 240 seconds)
08:07:12  * timoxleyquit (Remote host closed the connection)
08:10:26  * i_m_caquit (Ping timeout: 245 seconds)
08:12:41  * mirkokieferjoined
08:26:28  * maksimlinquit (Quit: ChatZilla [Firefox 23.0/20130803215302])
08:30:49  * dominictarrjoined
08:34:07  * mirkokieferquit (Quit: mirkokiefer)
08:37:53  * timoxleyjoined
08:45:44  * jergasonjoined
08:49:52  * jergasonquit (Ping timeout: 246 seconds)
08:53:41  <dominictarr>jaz303: idea: you just could just have icons on each window/widget/iframe that you could click and it would copy that object's address,
08:54:08  <dominictarr>then you could paste that into some other thing to get messages through to that thing
08:55:13  <dominictarr>computer -> mobile, a qr code would work fairly well, or this: http://smus.com/ultrasonic-networking/
08:56:55  * mcollinajoined
09:01:14  <jaz303>how does routing work?
09:01:19  <jaz303>s/does/could
09:02:49  <jaz303>sounds like you need to right down at the OS level
09:05:40  <dominictarr>so, you'd have a web/websocket server
09:05:47  <dominictarr>and browser tabs can connect to that
09:05:56  <dominictarr>websockets can do cross origin
09:06:05  <dominictarr>so there is a lot of flexilibity there
09:06:33  <dominictarr>basically, each thing routes to it's children
09:06:44  <dominictarr>and has more permissions than it's children
09:07:13  <dominictarr>so, if a child has an address it can't reach, it sends it to it's parent,
09:07:18  <dominictarr>(and so on)
09:07:33  <dominictarr>until someone can proxy that to the correct location.
09:08:19  <dominictarr>once you are at the socket server then you could make straight tcp connections
09:08:34  <dominictarr>and once on a local machine you can do unix pipes, or open file
09:08:36  <dominictarr>s
09:08:53  * defunctzombie_zzchanged nick to defunctzombie
09:09:07  <substack>dominictarr: new thing for streaming https://github.com/substack/level-assoc#live
09:09:22  <jaz303>i'm still a bit confused; let's say we want to connect to address x that is a thing living inside a machine with address y
09:09:46  <jaz303>what address do you type in to access it?
09:10:08  <substack>the best part is you can pipe a live stream and if a new parent doc gets inserted, you get that doc and you also get a stream of all its children
09:11:01  <dominictarr>jaz303: the address for x.y will be the x address with something appended on it
09:11:08  <jaz303>ah
09:11:12  <dominictarr>like twitter.com/jaz303
09:11:31  <dominictarr>but it's up to twitter to decide what scheme it wants to use there
09:12:17  <dominictarr>like, you can build a new house in your backyard and make it 1B infinite loop, cupidtino
09:12:19  <dominictarr>etc
09:12:29  <jaz303>so is it fair to say addresses are more like URLs?
09:12:37  <dominictarr>more or less
09:13:37  <dominictarr>and with urls you can usually mount a service under a prefix host.com/prefix/service etc!
09:13:57  <jaz303>yes understand now
09:14:18  <dominictarr>domains are weird because they are reverse. should be com.domain.subdomain.subsubdomain
09:15:47  <dominictarr>also, every object can have many addresses. like you probably have a phone number, an physical address, a mailing address (maybe) and an email.
09:16:00  <dominictarr>substack: nice
09:16:40  <dominictarr>I need to update level-sublevel to use gte, gt, lt, lte
09:18:52  * defunctzombiechanged nick to defunctzombie_zz
09:19:01  <dominictarr>check this out: DIY modem from the 70s http://www.classiccmp.org/cini/pdf/pe/1976/PE1976-Mar-pg43.pdf
09:21:47  <dominictarr>jaz303: also, there is webrtc which create a peer to peer connection between browsers (but only supported in chrome ff currently)
09:34:10  <dominictarr>Another thing that is needed is a way to directly connect devices that are on the same local network.
09:35:23  <dominictarr>so, if I have a server on my "dynabook" (aka laptop) running some webapp that you have open, the server you are connected to should notice that it's connected from the same ip address
09:35:32  <dominictarr>and tell you to try my local ip
09:35:52  <dominictarr>then, you could connect directly to that with no outside internet.
09:36:06  <dominictarr>this will be extremely helpful for development.
09:36:22  <dominictarr>(especially mobile development)
09:45:10  <dominictarr>ooh, this is interesting http://syntaxcandy.blogspot.ie/2012/08/perceptual-hash.html < need a level plugin for this
09:47:51  * ins0mniajoined
10:03:05  <daleharvey>weird, how do I run all the tests? http://pastie.org/8270498
10:03:57  * mirkokieferjoined
10:10:11  <dominictarr>daleharvey: authors should set their test command in scripts.test = cmd
10:10:16  <dominictarr>in package.json
10:10:20  <dominictarr>then you do `npm test`
10:10:51  <dominictarr>oh, and node only runs the first file
10:10:57  <dominictarr>I use:
10:11:22  <dominictarr>set -e; for t in test/*.js; do node "$t"; done
10:13:54  * mirkokieferquit (Quit: mirkokiefer)
10:15:50  * mirkokieferjoined
10:21:02  <daleharvey>cool cheers
10:24:33  * mcollinaquit (Read error: Connection reset by peer)
10:24:38  * mcollina_joined
10:25:17  <substack>daleharvey: you can use `tape test/*.js` as the scripts.test command
10:26:33  <daleharvey>even nicer, thanks
10:36:53  <daleharvey>ow wow, it seems in my previous refactor I got browserify support without realising it
10:36:58  <daleharvey>*oh
10:37:39  <daleharvey>although the bunch is 100kb larger than it should be, probably some stuff in there I dont need, but --list doesnt seem to work well with -i
10:38:41  <mcollina_>dominictarr: recently I was thinking about a REST on everything approach, tunnelling CoAP (http://datatracker.ietf.org/doc/draft-ietf-core-coap/) over WebRTC to build P2P web apps.
10:38:48  <daleharvey>know whats up with http://pastie.org/8270573 ?
10:39:09  <daleharvey>ignoring request, but dying on a request dep
10:39:17  <dominictarr>mcollina_: I hate REST
10:39:26  <dominictarr>I want duplex streaming connections
10:40:29  <mcollina_>REST is here to stay :P. But duplex streaming connections are way better!
10:40:53  <dominictarr>mcollina_: that is true, but we have websockets, and we can pollyfil duplex over rest
10:41:19  <dominictarr>people end up creating duplex like things on top of rest anyway
10:41:30  <mcollina_>yup
10:41:32  <dominictarr>like, long polling
10:41:58  <mcollina_>yeah!
10:42:03  <dominictarr>or even just pagination
10:42:43  <mcollina_>THe whole problem of WebSocket is that you end up building your own routing layer, while you get it for free with REST.
10:43:42  <dominictarr>with urls?
10:43:56  <dominictarr>websockets can have urls too
10:44:48  <dominictarr>http would be okay if browsers could do full duplex.
10:45:06  <dominictarr>you can use http to do full duplex with node <-> node
10:45:36  <dominictarr>but rest is different, the main idea being that rest is scaleable because it's designed for cacheableity
10:46:05  <mcollina_>which is quite the opposite of WebSocket :)
10:46:36  <dominictarr>yes, and this was over 10 years ago
10:46:47  <dominictarr>now we have node.js
10:47:56  <dominictarr>even in the fielding dissertation he says that clearly REST isn't ideal for cases, where you want realtime updates, but currently that takes too much resources...
10:49:21  <dominictarr>mcollina_: now, people are talking about millions of connections http://c10m.robertgraham.com/p/manifesto.html
10:49:54  <mcollina_>Well, our world right now is of both of them
10:50:06  <mcollina_>realtime updates and non-realtime updates.
10:51:27  <mcollina_>Meaning that most of the stuff out there is built on REST and it's a good fit.
10:51:52  <mcollina_>Click on a button -> do something on a server.
10:53:11  <dominictarr>sure, but a stream is a better lowest common denomenator
10:53:19  <dominictarr>http is over tcp, afterall
10:59:26  <dominictarr>but I agree, we are stuck with http.
10:59:44  <mcollina_>indefinitely
10:59:58  <dominictarr>we arn't gonna go back to tcp, but instead of the 7 layer model
11:00:13  <dominictarr>we'll just add polyfill layers into the application layer
11:00:21  <mcollina_>ahah yes
11:00:29  <dominictarr>tcp tunneled over http
11:16:00  <dominictarr>mcollina_: maybe we'll be able to get new ideas in around the side, though
11:16:13  <dominictarr>they'll just have to be backwards compatible with the polyfils
11:16:17  * nicholasfjoined
11:27:22  <daleharvey>crap, this works in browserify, thats pretty sweet
11:28:27  <daleharvey>so I have one issue, https://github.com/daleharvey/pouchdb/blob/master/src/pouch.js#L429
11:28:54  <daleharvey>I need to do an optional require based on browserify vs node
11:29:39  <daleharvey>in browserify I need to require pouch.idb.js + pouch.websql.js, in node I need pouch.leveldb.js
11:37:11  <dominictarr>daleharvey: best way is to have a different entry file for browser bundle, with this https://gist.github.com/shtylman/4339901
11:38:23  <daleharvey>that file is a common global entry point, not sure how that would be possible
11:45:00  <daleharvey>I create a pouch.browser.js and required idb in that, that worked, however I really want to be able to require('pouch.js') in the test suite and have it work in browserify + node
11:45:18  <dominictarr>you can do that
11:45:31  <dominictarr>in package.json, main: pouch.node.js
11:46:47  <dominictarr>and browser: pouch.browser.js
11:46:53  <daleharvey>the tests are inside the repo though, a module cant require itself can it ?
11:47:21  <dominictarr>here is an example https://github.com/dominictarr/reconnect/blob/master/package.json#L24-L27
11:47:30  <dominictarr>daleharvey: you have to do require('../')
11:47:39  <dominictarr>(unfortunately)
11:47:55  <dominictarr>or you can add a symlink
11:48:12  <dominictarr>./test/node_modules/pouch -> ./
11:49:00  <dominictarr>but that will break if anyone trys to run the tests from the npm module because npm doesn't preserve symlinks (because windows)
11:50:26  <daleharvey>hmm, this seems to break browserify's module path lookup
11:57:16  <dominictarr>daleharvey: the symlink?
11:57:56  <daleharvey>nah, the ../
11:58:37  <daleharvey>oh wait, may be my bug
12:10:00  * timoxleyquit (Read error: No route to host)
12:10:25  * timoxleyjoined
12:13:27  <daleharvey>heh, slightly hacky, but this works, can clean it up later, the ../ trick half worked, but I am using a global object which gets modified and it screwed that up in weird ways
12:13:29  <daleharvey> require('./adapters/pouch.idb.js');
12:13:29  <daleharvey> if (typeof window === 'undefined') {
12:13:29  <daleharvey> require('./adapters/pouch.' + 'leveldb' + '.js');
12:13:29  <daleharvey> }
12:13:56  <daleharvey>we can include idb anyway, it wont break in node, just unused
12:15:21  <dominictarr>daleharvey: you can tell it to ignore modules with the browser option too
12:15:33  <dominictarr>'./adapters/pouch.leveldb' : false
12:15:47  * mirkokieferquit (Quit: mirkokiefer)
12:16:24  <dominictarr>daleharvey: also, the best way to detect whether you are in browser or node is process.title !== 'browser' => you are in node.
12:16:43  <daleharvey>sweet thanks
12:16:50  <dominictarr>window isn't defined in webworkers
12:17:13  <dominictarr>but you can still access indexeddb, I think
12:17:24  <daleharvey>not in web workers in ffx
12:17:50  <daleharvey>but thats being fixed, will switch to yours
12:18:21  <daleharvey>actually that wont work, this still supports being run in a plain browser (sans browserify)
12:19:18  <daleharvey>heh I should have paid more attention, I dont need to care about importing leveldb either, it wont break anything, just unused again
12:24:38  * fotoveritequit (Quit: fotoverite)
12:26:48  <dominictarr>daleharvey: you could just bundle with browserify --standalone
12:27:40  <dominictarr>that gets you a 'normal' script tag that people who arn't using browserify yet can use
12:29:25  <daleharvey>this is pretty close to running how I want it, cheers for the help
12:34:41  <dominictarr>daleharvey: no problem
12:35:14  <dominictarr>substack: mbalho juliangruber ins0mnia binary over sockjs: https://github.com/sockjs/sockjs-protocol/issues/74
12:36:53  <daleharvey>this is strange
12:36:58  <daleharvey>http://pastie.org/8270830
12:37:17  <daleharvey>the browserify packages is 229K vs 154k for nightly, same files
12:38:05  <daleharvey>actually nightly has extra files
12:39:09  <ins0mnia>dominictarr: it would've been great if this was possible, I asked a similar question in #sockjs but it seems everyone is just idling there
12:39:53  <dominictarr>ins0mnia: it would be a fairly big bit of work.
12:40:07  <ins0mnia>dominictarr: Chrome, Browserify, Safari and IE10 support TypedArray it makes sense
12:40:18  <dominictarr>so, the maintainers won't be jumping out of thier seats to do it.
12:40:28  <ins0mnia>dominictarr: yeah I guess not...
12:40:32  <dominictarr>but, if you made a pull request, and did it well
12:40:41  <dominictarr>and it was backwards compatible...
12:40:45  <dominictarr>I think they might take it.
12:40:55  <dominictarr>also, they have a spec!
12:41:06  <ins0mnia>dominictarr: my problem with sockjs is that they whole thing is in coffescript
12:41:11  <dominictarr>so, you could build another implementation that was compatable
12:41:15  <dominictarr>ins0mnia: who cares?
12:41:31  <dominictarr>they have a spec. that is the most important thing
12:41:41  <ins0mnia>dominictarr: I hate coffescript it makes me want to throw up I'd probably need to look into sockjs itself
12:41:46  <daleharvey>it looks like there is some buffers stuff in the browserify version that takes up a ton
12:41:47  <dominictarr>the spec is in mython
12:41:50  <dominictarr>python
12:42:18  <dominictarr>daleharvey: right - that gets inserted if you use buffers
12:42:34  <dominictarr>daleharvey: are you using binary?
12:43:07  <dominictarr>ins0mnia: maybe reimplement sockjs in pure js with browserify?
12:43:16  <dominictarr>how hard could it be?
12:43:39  <ins0mnia>dominictarr: it's the fall back stuff they're doing which makes sockjs interesting
12:43:56  <dominictarr>agree, but that could have binary support too
12:44:19  <ins0mnia>yeah there's no reason it shouldn't.. I mean it's just data..
12:44:29  <ins0mnia>sockjs shouldn't care about that
12:44:43  <daleharvey>I noticed browserify still traverses modules even if you ignore a top level module, seems like it may be that
12:44:44  <dominictarr>just use base64 on jsonp etc
12:44:52  <daleharvey>the level implementation uses buffers
12:45:00  <ins0mnia>that's 30% increase in the packet size
12:45:00  <daleharvey>thye dont show up in --list though
12:45:16  * mirkokieferjoined
12:45:22  <dominictarr>ins0mnia: but if you need binary, you have to do that anyway
12:45:26  <ins0mnia>bandwidth is more expensive that storage
12:45:42  <ins0mnia>dominictarr: yes, but this can be acheived on the client
12:45:51  <dominictarr>ins0mnia: this is only on the bad fallbacks
12:45:58  <dominictarr>the good ones get straight binary
12:46:07  * mcollina_quit (Read error: No route to host)
12:46:26  <dominictarr>daleharvey: what browserify version are you on?
12:46:40  <daleharvey>2.29
12:47:03  <ins0mnia>dominictarr: yeah on the bad fallbacks it makes sense then
12:48:12  <ins0mnia>dominictarr: in one year or two IE8/9 would hopefully be rotten dead
12:48:45  <dominictarr>they will live on in the enterprise
12:49:07  <dominictarr>also, on pirated win ex in china
12:49:10  <daleharvey>this is working as I want it for now, its 'browserifyable', I can write the tests the way I want, and I can still use my existing build / packaging tools
12:49:14  <dominictarr>xp
12:49:33  <daleharvey>will open an issue for the nested ignores and take a look if we switch to full browserify down the line
12:49:38  <dominictarr>daleharvey: okay, cool
12:49:42  <ins0mnia>yeah...
12:49:45  * jcrugzzjoined
12:51:02  * thlorenzjoined
12:51:16  <ins0mnia>even engine.io only supports utf-8 strings, no binary
12:51:41  <dominictarr>daleharvey: what are you using to bundle at the moment, I see lots of requires in there?
12:52:09  * ins0mniaafk
12:52:22  <daleharvey>https://github.com/daleharvey/pouchdb/blob/master/Gruntfile.js#L11
12:53:53  <daleharvey>will likely get rid of grunt, its just annoying
12:56:08  <dominictarr>daleharvey: browserify is including Buffer stuff because of this https://github.com/daleharvey/pouchdb/blob/master/src/pouch.utils.js#L292
12:56:52  <dominictarr>if that isn't used in browsers you'd have to move it to a separate thing.
12:57:50  <daleharvey>ah cause buffers are in built
12:58:39  <dominictarr>daleharvey: we use https://github.com/chrisdickinson/bops to get portable binary
12:59:58  * thlorenzquit (Remote host closed the connection)
13:00:32  <daleharvey>sure, but for now trying to avoid adding any unneeded code
13:00:41  <daleharvey>cheers for finding
13:01:15  * thlorenzjoined
13:03:29  <dominictarr>yeah, you'd probably want to just move those functions into another file that is ignored if you where to use browserify
13:05:54  <daleharvey>yay, level is segfaulting now
13:06:09  <daleharvey>dont think this has to do with my changes though
13:08:19  * kevino80joined
13:10:50  <ins0mnia>dominictarr: think we could get mux demux to work with max's websocket-stream?
13:10:56  <ins0mnia>it should be possible, in theory
13:11:54  <dominictarr>ins0mnia: yes, it works
13:12:35  <ins0mnia>cool
13:12:52  <ins0mnia>so in theory
13:12:53  * mirkokieferquit (Quit: mirkokiefer)
13:13:05  <ins0mnia>websocket-stream can be a starting point
13:13:14  <ins0mnia>with some sort of ajax+cors fallback for older browsers
13:13:39  * mirkokieferjoined
13:15:32  <ins0mnia>like, no websockets = some basic ajax protocol with a similar interface so that 'data', 'end', 'error' events are more or less the same
13:16:13  <ins0mnia>a websocket interface based on ajax
13:16:28  <ins0mnia>with http polling
13:18:57  * thlorenzquit (Remote host closed the connection)
13:21:59  <dominictarr>ins0mnia: yes, that would just be a binary version of sockjs
13:22:20  <dominictarr>well, cept with streams
13:22:46  * jergasonjoined
13:23:03  <dominictarr>but it's the same diff. would be better to get it into sock.js because then there are other people who understand the code.
13:23:14  <dominictarr>and a spec and tests
13:29:20  * kevino80quit (Remote host closed the connection)
13:29:35  <ins0mnia>dominictarr: yeah, let's not hope that sockjs, internally, doesn't expect the data to be a string
13:29:43  <ins0mnia>not=just
13:30:28  * kevino80joined
13:30:45  <daleharvey>woot, thats browserify supported
13:31:16  <dominictarr>that is probably something easy to support, just add bops.is(message) next to 'string' === typeof message
13:31:23  <dominictarr>daleharvey: sweet!
13:52:27  * jcrugzzquit (Ping timeout: 276 seconds)
13:56:53  * mcollinajoined
13:58:47  * thlorenzjoined
14:06:20  * fallsemojoined
14:16:42  * kenperkinsjoined
14:20:51  <dominictarr>everyone in stackvm should read this http://worrydream.com/EarlyHistoryOfSmalltalk/
14:26:30  * dguttmanjoined
14:31:33  * coderzachjoined
14:32:00  * yorickjoined
14:32:39  <jesusabdullah>MAYBE I WILL
14:33:03  * jcrugzzjoined
14:35:51  <daleharvey>woot - https://github.com/daleharvey/pouchdb/blob/master/test/integration/basics_test.js
14:36:33  <daleharvey>compared to the setup I was doing in https://github.com/daleharvey/pouchdb/blob/master/tests/test.basics.js#L1, so much nicer
14:37:32  <daleharvey>still need to do setup / teardown and options passing though
14:39:01  <daleharvey>may switch back to mocha for that stuff since it doesnt look like tape does it, but now that its browserified the tests are gonna be much cleaner
14:45:19  * AvianFlujoined
14:45:22  <dominictarr>daleharvey: tape tests run in order, so you can just do setup in the first test
14:45:43  <dominictarr>there is no teardown, but just cleanup the previous test in the setup.
14:46:28  <daleharvey>everything else runs them in order too, but I still need setup / teardown for indiviual tests
14:51:55  <dominictarr>just make a thing: tape('test', withSetupAndTeardown(function (t) {…}))
14:52:09  <dominictarr>and it injects setup...
14:52:34  <dominictarr>hmm, teardown is more problematic
14:53:05  <dominictarr>… because if the test fails the state could be messy
14:54:10  <daleharvey>thats kindoff ok, the setup has to handle the case that the test completely died anyway
14:55:49  <daleharvey>but both setup and teardown are async, cant quite see if that will be possible to do and still get proper ordering, but will give it a test
14:59:54  * calvinfojoined
15:00:41  <dominictarr>daleharvey: that was what I meant by in order - tape doesn't start the next test until the first is t.end()
15:00:57  <dominictarr>"serially" i should have said.
15:04:18  * evboguejoined
15:07:45  * kevino80quit (Remote host closed the connection)
15:09:20  * kevino80joined
15:14:32  * shamajoined
15:22:08  * coderzachquit (Quit: coderzach)
15:23:19  * stagasquit (Ping timeout: 264 seconds)
15:26:48  * thlorenzquit (Remote host closed the connection)
15:27:32  * stagasjoined
15:34:45  * brianloveswords_changed nick to brianloveswords
15:43:33  * thlorenzjoined
15:47:26  * thlorenzquit (Remote host closed the connection)
15:48:01  * thlorenzjoined
15:50:25  * thlorenz_joined
15:50:33  * thlorenz_quit (Remote host closed the connection)
15:50:35  * thlorenzquit (Read error: Connection reset by peer)
15:51:08  * thlorenzjoined
15:51:41  * djcoinquit (Quit: WeeChat 0.4.0)
15:54:02  * coderzachjoined
15:59:54  * mcollinaquit (Read error: Connection reset by peer)
16:03:37  * calvinfoquit (Quit: Leaving.)
16:12:49  * calvinfojoined
16:15:24  * fotoveritejoined
16:18:26  * dguttmanquit (Quit: dguttman)
16:19:54  <daleharvey>substack / dominictarr any way to catch when a test has ended?
16:20:14  <daleharvey>http://pastie.org/8271409
16:22:10  <dominictarr>daleharvey: no… you could patch t.end
16:22:25  <dominictarr>but not calling t.end is a way to fail
16:22:41  <dominictarr>simplest is just to not rely on teardowns at all
16:23:06  <dominictarr>what do you need it for?
16:23:50  <daleharvey>so I dont fill my browser with test databases (they use randomly generated names)
16:24:47  <daleharvey>or the server for that matter
16:25:57  <daleharvey>will just switch back to mocha, getting the browserified stuff working nicely was the important bit
16:26:43  * mirkokieferquit (Quit: mirkokiefer)
16:27:03  <dominictarr>daleharvey: mocha works with drowserify too, anyway
16:31:19  * AvianFluquit (Remote host closed the connection)
16:31:22  * dominictarrquit (Quit: dominictarr)
16:31:27  <daleharvey>yeh I started with mocha but its browser version sucks, so this could be best of both worlds
16:32:07  * evboguequit (Quit: Lost terminal)
16:32:44  * evboguejoined
16:40:16  * AvianFlujoined
16:58:21  * evboguequit (Ping timeout: 245 seconds)
16:59:53  * dguttmanjoined
17:03:17  * dguttmanquit (Client Quit)
17:04:38  * kumavis_joined
17:10:00  * mirkokieferjoined
17:13:16  * AvianFlu_joined
17:15:57  * dominictarrjoined
17:16:35  * AvianFluquit (Ping timeout: 260 seconds)
17:17:00  <Raynos>thlorenz: whats wrong with those repos?
17:17:13  <Raynos>rvagg: ping
17:24:48  * jxsonjoined
17:31:29  * timoxleyquit (Remote host closed the connection)
17:35:12  * AvianFlu_changed nick to AvianFlu
17:41:44  <Raynos>dominictarr: pong
17:42:29  <dominictarr>Raynos: hey whats up?
17:42:46  <Raynos>you said hey earleir
17:43:07  <dominictarr>Raynos: yes, I wanted to ask your opinion on something
17:43:48  <dominictarr>I've been thinking: that frontend frameworks need better abstractions
17:44:00  <dominictarr>like, avoid the messy parts of the dob
17:44:02  <dominictarr>dom
17:44:19  <dominictarr>and abstract out the parts that are universal
17:44:29  * st_lukejoined
17:44:46  <dominictarr>in particular, use a better point/box model
17:45:10  <dominictarr>have been using this https://github.com/tmpvar/vec2.js
17:45:25  <dominictarr>and making things like this: http://dominictarr.github.io/vec2-layout/
17:47:17  <Raynos>i see
17:47:22  <Raynos>i dont understand how layout works
17:47:25  <Raynos>i looked at the xample
17:47:29  <Raynos>and all I see is layout(elem)
17:47:40  <Raynos>and elem.layout(grid || tile)
17:47:52  <dominictarr>there is a function that is passed in, that provides the laying out
17:47:58  <dominictarr>see tile.js and grid.js
17:48:15  <Raynos>I see
17:48:20  <Raynos>tile is meant to look like that
17:48:41  <dominictarr>I adapted tile from nwm, a tiling window manager for node
17:48:46  <dominictarr>(and grid)
17:48:52  <Raynos>what is element.set ?
17:49:08  <Raynos>https://github.com/dominictarr/vec2-layout/blob/master/tile.js#L16
17:49:25  <dominictarr>oh, I should change that name
17:49:52  <dominictarr>instead of being passed htmlelements it gets past rec2 (subclass of vec2)
17:49:56  <Raynos>I see
17:50:08  <dominictarr>that represents the position and dimentions of the element
17:50:13  <dominictarr>using absolute positioning.
17:50:37  <Raynos>Ok
17:50:45  <Raynos>I agree we need better primitives
17:50:48  <Raynos>this looks interesting
17:50:52  <dominictarr>so - html layout shoudl only be used to layout text
17:50:58  <dominictarr>to typeset.
17:51:04  <dominictarr>that is what it's designed for
17:51:30  <dominictarr>ALSO: vec2 has a .changes(listener)
17:51:45  <dominictarr>thing, so you can do FRP with it too
17:52:15  <Raynos>cool
17:53:32  <dominictarr>but, the specific thing I wanted to ask was this:
17:53:46  <dominictarr>I'm adding properties to the elements https://github.com/dominictarr/vec2-layout/blob/master/index.js#L7
17:54:26  <dominictarr>but, I was wondering how you would do this?
18:04:50  * nicholasfquit (Ping timeout: 240 seconds)
18:04:53  * nicholas_joined
18:07:19  * mikolalysenkojoined
18:16:25  * dguttmanjoined
18:17:26  <jlord>does anyone here k now about stock??
18:17:49  <jlord>ohh wait i thought i was in the other room
18:17:51  <jlord>blehh
18:20:01  * evboguejoined
18:21:46  <mbalho>you know youre in the bay area when...
18:24:15  * jxsonquit (Remote host closed the connection)
18:25:27  * jxsonjoined
18:27:18  * mbrevoortjoined
18:27:41  <mbrevoort>dominictarr: hi
18:27:52  <dominictarr>mbrevoort: hey, this thing is weird
18:28:02  <mbrevoort>yeah :)
18:29:25  <dominictarr>so, how is the server's message getting mixed into the client's message?
18:30:29  <dominictarr>is it the server or the client that emits the error?
18:30:49  <dominictarr>mbrevoort: what do the colors mean?
18:31:18  <mbrevoort>I'm not sure, but what the server is sending seems to be getting emitted into or echodd (or something) into the scuttlebutt stream that the server is reading. For example, here's that latter bit of what is JSON parsed...
18:31:24  <substack>daleharvey: t.on('end', fn) and test().on('end', fn) both work
18:31:52  <mbrevoort>https://s3.amazonaws.com/uploads.hipchat.com/20895/99444/clg3v6hqxqex7do/Screen+Shot+2013-08-26+at+12.28.54+PM.png
18:32:32  <mbrevoort>dominictarr: so the red is data in the tcp stream coming from the "client" and the blue is data being sent from the "server"
18:32:51  <dominictarr>and who is throwing?
18:33:48  <mbrevoort>dominictarr: on the server, the stream-serializer is getting the 1st packet plus the packet in blue that he sent and trying to JSON parse that
18:34:14  <dominictarr>do you have a stacktrace?
18:34:41  <dominictarr>also, does this happen every time?
18:34:45  <thlorenz>Raynos: the npm packages are missing repo urls
18:34:47  <dominictarr>or only sometimes?
18:35:13  <thlorenz>I need some stream help - been banging my head against the wall for over an hour now: https://github.com/thlorenz/browserify-dedupe/blob/master/index.js#L33-L37
18:35:39  <thlorenz>the comments explain what my problem is, maybe dominictarr you know what is going on here?
18:35:49  <mbrevoort>dominictarr: not for this specific case (from screenshots) but all look like this: https://gist.github.com/mbrevoort/6344896
18:36:22  <dominictarr>what node version?
18:36:52  <dominictarr>thlorenz: this problem is urgent. will look at yours in a bit
18:37:00  <thlorenz>ok thanks np
18:37:18  <mbrevoort>dominictarr: no not happening everytime. Node 0.10.16
18:37:36  <dominictarr>mbrevoort: how oftenL
18:37:37  <dominictarr>L
18:37:39  <dominictarr>?
18:38:08  <mbrevoort>right now it's happening very often :(
18:38:25  <dominictarr>how many instances are there?
18:38:56  <mbrevoort>seaport wasn't handling the error on the stream and it's causing the server process to exit
18:39:37  <dominictarr>does it restart it automatically?
18:39:59  <dominictarr>also: how does seaport persist it?
18:40:07  <mbrevoort>So there's a lot of orphaned data that's accumulating every time it throws and restarts and it's not getting a chance to clean itself up, meanwhile all of the clients are just trying to sync all of the bad data back to the server
18:40:37  <mbrevoort>upstart restarts the process... seaport doesn't persist it to disk, only in memory
18:40:47  <dominictarr>hmm… oh, okay.
18:40:51  <mbrevoort>So it has to resync everything
18:41:31  <dominictarr>hmm. okay… okay, one thing that should work… although it's a hack would be to disable the vector clocks
18:41:43  <dominictarr>when it connects it would just send everything
18:43:36  <mbrevoort>so luckily this is not happening in production at the moment, but in a test environment with about 100 instances... hehe I would have to do that to all of the instances
18:44:47  <mbrevoort>but I've got it in this crazy state where it's spinning out of control, trying to not lose to opportunity to root out what's going on in a scenario that may be hard to reproduce
18:45:15  <dominictarr>okay, cool
18:45:26  <dominictarr>are you using the sendClock?
18:45:30  <dominictarr>option?
18:47:04  <mbrevoort>no, but both are writable streams - I thought that only applied to just readable streams... ?
18:47:46  <mbrevoort>any idea how the streams could be getting crossed? http://longboxgraveyard.files.wordpress.com/2011/11/371-dont-cross-the-streams.jpg
18:48:26  <dominictarr>indeed. that is just what I'm trying to figure out
18:48:52  * jxsonquit (Remote host closed the connection)
18:49:31  * jxsonjoined
18:50:51  <dominictarr>mbrevoort: are you using stock seaport? or a modified seaport?
18:51:02  * jxsonquit (Read error: No route to host)
18:51:09  * kumavis_quit (Quit: kumavis_)
18:51:20  <mbrevoort>dominictarr: no, it's stock... the latest
18:51:29  * jxsonjoined
18:51:44  * evboguequit (Quit: Lost terminal)
18:51:45  <mbrevoort>besides my own layer, nothing's forked at this point
18:51:59  <dominictarr>aha, okay
18:53:28  * kumavis_joined
18:53:42  <dominictarr>https://github.com/substack/seaport/blame/master/lib/seaport.js#L190-L194
18:53:44  <dominictarr>this is weird
18:54:23  <dominictarr>this will break pausing i think
18:54:45  * defunctzombie_zzchanged nick to defunctzombie
18:56:06  <dominictarr>yeah, I think this is about backpressure.
18:56:33  <mbrevoort>interesting
18:57:55  <dominictarr>although… not sure how that gets the packets mixed up
18:58:04  <dominictarr>that code is definately out of order.
18:59:01  <dominictarr>mbrevoort: what level of emergency is this for you right now?
19:00:26  <mbrevoort>dominictarr: not affecting production, though I'm blocked until I work through this or do something drastic - mediumish
19:00:37  <dominictarr>okay, cool.
19:01:02  <dominictarr>so, lets fix this the right way.
19:01:35  <mbrevoort>dominictarr: thank you :) you're amazing
19:02:25  <dominictarr>okay, so, this line https://github.com/substack/seaport/blame/master/lib/seaport.js#L191
19:02:26  <mbrevoort>So what about that code would break pausing (still wrap my brain in knots sometimes with streams)
19:02:53  <dominictarr>^ the way that s and tr are coupled together
19:03:03  * evboguejoined
19:04:33  <mbrevoort>binding to those events yet still piped?
19:04:44  <dominictarr>yeah.
19:05:08  <dominictarr>when s emits data gets written to tr
19:05:25  <mbrevoort>oh, it's just piped one way and then selectively binding to events the other way?
19:05:27  <dominictarr>and then look at tr = through(write)
19:05:49  <dominictarr>write (data) { s.write(data) /* !!! */ }
19:06:57  <dominictarr>when s emits data… it's gonna get written back to s!
19:07:18  <dominictarr>so, if s has recieved half a message… and then it emits a message
19:07:25  <dominictarr>bamm!
19:07:54  <dominictarr>it's interrupted you by talking to it self!
19:08:56  <dominictarr>I'm gonna contruct a test case to check...
19:10:01  <mbrevoort>but does that explain why the message written by the "server" gets wrote back to the client's stream?
19:10:19  <mbrevoort>oh
19:11:05  <mbrevoort>yeah, I can sort of see how that can happen... let me write out some debug and try to validate too
19:11:32  <Raynos>thlorenz: yeah those packages suck anyway :p
19:11:51  <thlorenz>:)
19:14:26  <dominictarr>so, when a large packet comes in, it gets one bit and then another
19:14:39  <dominictarr>so part could be sitting in the buffer when the second write is called
19:15:21  <mbrevoort>the 1st part is sitting in the buffer when the extraneous message comes through
19:16:21  <dominictarr>yeah
19:16:48  * stagasquit (Ping timeout: 276 seconds)
19:16:51  <dominictarr>because the client connects and sends the first message
19:17:11  <dominictarr>(the first packet is always from client… see tcp state diagram)
19:18:04  <dominictarr>so, on a new connection I can see that there would be a message sitting there..
19:18:28  <dominictarr>and since it's a large packet, it's gonna wait for a packet from the server to send a packet back
19:18:48  <dominictarr>now, this stream is in {writable: false} correct?
19:19:30  <mbrevoort>no, it is writable
19:20:03  <dominictarr>{writable: true}
19:20:18  <dominictarr>or seaport.createWritableStream()
19:20:58  <mbrevoort>I thought it was writable by default?
19:20:59  <mbrevoort>no?
19:21:06  <dominictarr>it's duplex by default
19:21:25  <dominictarr>I'm just checking because I remember you posted an issue on this a few months ago
19:21:54  <mbrevoort>yeah, that was for another somewhat related CRDT use
19:22:07  <dominictarr>okay, cool
19:22:27  <mbrevoort>however I am considering this too: https://github.com/substack/seaport/issues/38
19:23:47  <dominictarr>you could certainly have a feature that filtered the Docs that a particular client is interested in
19:23:59  <dominictarr>if you are using it with a centralized server
19:24:27  <mbrevoort>centralized servers that could be peered
19:26:43  <dominictarr>okay… I think this is combining with a scuttlebutt bug too
19:27:16  <dominictarr>because writing back the message isn't enough to explain it
19:27:27  <dominictarr>the other problem is here: https://github.com/dominictarr/scuttlebutt/blob/master/index.js#L219
19:27:47  <dominictarr>the internat update listener is being registered before data is sent
19:28:22  <dominictarr>so there is a race condition, if an update happens before the first client clock is recieved.
19:28:38  <dominictarr>which would normally never happen, unless the first packet is split!
19:28:49  <mbrevoort>wow
19:29:28  <dominictarr>wonder when that was introduced
19:31:19  <dominictarr>hmm, looks like it's always been there
19:31:57  <dominictarr>anyway, it should only register the update listener after it's sent the history
19:33:08  <dominictarr>okay, I've got a patch to seaport that passes the tests, I'll fix this in scuttlebutt too, and put a PR into seaport.
19:33:25  <dominictarr>substack should be waking up shortly :) and he'll be able to merge it
19:34:00  <mbrevoort>hehe - does that explain the entire issue?
19:34:25  <mbrevoort>let's say it's not the client clock message but a really large update that's split
19:35:14  <mbrevoort>should it not write into the middle of a message that's being received?
19:36:59  <jesusabdullah>What's all this?
19:37:50  <mbrevoort>jesusabdullah: related to this: https://github.com/dominictarr/scuttlebutt/issues/27
19:38:05  <jesusabdullah>aha
19:39:09  <jesusabdullah>whatcha usin' scuttlebutt for?
19:41:06  <mbrevoort>currently using seaport -> CRDT -> Scuttlebutt to register apps and dynamically configure haproxy instances... also now to stream haproxy config and status... and to peer proxies (commute on that config)
19:41:48  <mbrevoort>and all that mux'd streaming to the browser to visualize
19:41:59  <dominictarr>mbrevoort: well, the streams getting crossed was caused by the problem is seaport
19:42:10  <dominictarr>but also, there was a message out of order
19:42:57  <dominictarr>normally, the server doesn't send any messages until it's recieved a handshake
19:43:20  <mbrevoort>ah, OK. I'll wait to see your PR on seaport.
19:43:24  <dominictarr>so it was very strange that it was writing a message at that pont anyway.
19:43:57  <mbrevoort>the server does register back on itself which would happen almost immediately
19:44:55  <dominictarr>hmm, that -- or the fact that the server sends it's own clock to it self
19:45:04  <dominictarr>which then makes it think it's time to get started
19:47:42  <mbrevoort>hmmm let me look. I think the server connects to itself as a client which means it has two copies of the document. obviously not the most efficient thing but it just uses that same client library... might be something there though
19:48:40  * nicholas_quit (Read error: Connection reset by peer)
19:49:04  * nicholasfjoined
19:51:38  * kumavis_quit (Quit: kumavis_)
19:53:33  <mbrevoort>dominictarr: yeah, the server connects back on itself over tcp currently so the two docs should be distinct but that will happen immediately at startup while other remote clients are connecting
19:54:18  <mbrevoort>seaport doesn't expose a way to do it so that was just cleaner and more consistent for now
20:06:22  <substack>beep boop
20:14:30  <dominictarr>Raynos: substack Domenic_ isaacs what does a stream2 do when if the source emits close prematurely?
20:14:47  <dominictarr>I remember it doesn't call destroy like a streams1 does
20:17:53  <Domenic_>dominictarr: no real idea but https://github.com/joyent/node/blob/master/lib/_stream_readable.js#L562-L565
20:18:36  <dominictarr>oh! destroy() will get called, because it will be stream1.pipe(stream2)
20:18:45  <dominictarr>so it will get called by stream1
20:20:58  * jxsonquit (Remote host closed the connection)
20:22:01  * st_lukequit (Remote host closed the connection)
20:23:43  * jxsonjoined
20:24:03  * st_lukejoined
20:24:23  <dominictarr>substack: mbrevoort https://github.com/substack/seaport/pull/41
20:27:01  <dominictarr>oh no! node just official became uncool! https://www.ibm.com/developerworks/mobile/library/mo-nodejs-1/
20:28:11  <mbrevoort>dominictarr: AWESOME - I'll try this ASAP --- THANK YOU!
20:28:20  * mikolalysenkoquit (Ping timeout: 268 seconds)
20:28:35  <st_luke>dominictarr: thank science
20:28:41  <st_luke>I hope it becomes as uncool as humanly possible
20:30:06  <dominictarr>st_luke: hmm, maybe we need IMB to sponsor node.js themed crocs?
20:30:10  <substack>mbrevoort: pushlished in 1.5.3
20:30:21  <st_luke>dominictarr: crocks are too far
20:30:34  <st_luke>there's a difference between cool and sad
20:30:46  <substack>IBM EXTREME BLUE TEAM, GO
20:30:56  <dominictarr>right just calibrating my scale
20:31:08  <dominictarr>what defines 0 cool to st_luke ?
20:31:21  <mbrevoort>substack: thanks!
20:31:41  <substack>and they're using mongodb because webscale
20:31:44  <substack>good to see
20:31:45  <st_luke>dominictarr: non handicapped people who park in handicapped parking spaces
20:32:38  <dominictarr>I'd class that more as an "asshole"
20:33:06  <substack>hah DB2!
20:33:22  <substack>my mom learned DB2 in the 80s
20:33:42  <substack>there's still an old book lying around my parent's house about it
20:33:48  <mbrevoort>w/ cobol?
20:36:39  * mk30_joined
20:36:43  <substack>"This concept is referred to as JavaScript Everywhere"
20:37:24  <substack>[citation needed]
20:37:55  <dominictarr>40% less time to build that java
20:38:11  <dominictarr>and I'm assuming that they probably wrote pretty java like code
20:43:23  * jxsonquit (Remote host closed the connection)
20:43:58  * kumavis_joined
20:49:17  * calvinfoquit (Quit: Leaving.)
20:49:34  * coderzachpart
20:50:19  * mikolalysenkojoined
20:56:52  <st_luke>Domenic_: lots of issues opened lately where the issue belongs somewhere else
20:57:08  <st_luke>by lots i guess i mean more than usual
20:57:24  <Domenic_>st_luke: yeah..
21:01:08  <juliangruber>how can I find out what keeps the event loop from quitting?
21:01:33  <robertkowalski>hey
21:02:22  <robertkowalski>st_luke: maybe we can tweak something on the error messages again?
21:04:09  * shamaquit (Read error: Connection reset by peer)
21:04:33  * shamajoined
21:06:56  <robertkowalski>isaacs, Domenic_, st_luke seems like forbes lindesay has finished large parts of npm-fetch yesterday night, so we can replace large parts of the cache.js with it ( https://github.com/ForbesLindesay/npm-fetch )
21:07:08  <Domenic_>:D
21:07:40  * Guest55119changed nick to jden
21:08:06  <isaacs>robertkowalski: bajtos is working on strong-caching-http-client which might be useful here, as well.
21:10:05  * calvinfojoined
21:10:42  <dominictarr>mbrevoort: did that work?
21:11:19  <isaacs>robertkowalski: it looks like npm-fetch does not do caching?
21:12:08  <robertkowalski>isaacs: nope - it just returns streams that you could pipe into a cache
21:12:19  <robertkowalski>or through
21:12:45  <isaacs>gotcha..
21:12:58  <isaacs>well, that's not quite ideal, then
21:13:06  <mbrevoort>dominictarr: YES - just finish testing it and it's a resounding success :)
21:13:14  <isaacs>i mean, i'd want the http layer to just do caching transparently
21:13:40  <mbrevoort>dominictarr: thanks again! I definitely owe you some beer(s)
21:14:06  <dominictarr>haha, I'll be at realtimeconf in october!
21:14:30  * jxsonjoined
21:15:24  <mbrevoort>grrr not making it again this year though I will be at LXJS :)
21:15:36  <jesusabdullah>heh
21:17:04  <jesusabdullah>I think I'm-a fork over the dough for cascadiajs if my talk doesn't get accepted
21:18:39  <juliangruber>substack: having problems killing a `npm start` process, the raw `node bin/...` works well. I think you had the same problem with ploy, didn't you?
21:19:52  <dominictarr>mbrevoort: aha cool, see you then!
21:20:14  * AvianFlu_joined
21:20:28  * AvianFlu_quit (Remote host closed the connection)
21:22:05  <robertkowalski>isaacs: for details see https://github.com/ForbesLindesay/npm-fetch/issues/24 but i think transparent caching could be added later on without problems.
21:22:56  <substack>juliangruber: yes, `npm start` traps a bunch of signals
21:23:12  <st_luke>robertkowalski: what were you thinking about tweaking on the error messages?
21:23:16  <isaacs>robertkowalski: well, all it would take is for npm-fetch to allow a configurable http agent to use
21:23:17  <substack>juliangruber: just don't use it if you're going to run `npm start` from a script
21:23:26  * AvianFluquit (Ping timeout: 246 seconds)
21:23:38  <robertkowalski>i would liked to have something like a strategy-cache but that would not be transparent.
21:24:00  * jxsonquit (Ping timeout: 256 seconds)
21:25:27  <evbogue> /connect irc.efnet.org
21:25:38  <evbogue>partyfoul
21:26:27  <mbalho>evbogue: theres a little star pizza on grand ave in oakland called 'the star'
21:27:17  * coderzachjoined
21:28:48  <robertkowalski>isaacs: i'll open an issue with your feedback.
21:29:55  <robertkowalski>st_luke: just a thought without knowing the exact issues. thought about something like the error messages for a "missing git" or "bad network"
21:30:15  <evbogue>mbalho: cool!
21:30:32  <juliangruber>substack: ok, got it!
21:31:07  <Domenic_>isaacs: robertkowalski: I never understood the desire to couple caching to npm fetch. it seems like what got us into this problem in the first place. On the other hand, the transparently-caching agent idea is an interesting one.
21:34:15  * Ralt_changed nick to Ralt
21:37:16  * dguttmanquit (Quit: dguttman)
21:37:38  <isaacs>Domenic_: yeah, another thing is that it has to support tunneling https-over-http
21:37:53  <isaacs>Domenic_: so, the strong-caching-omg-this-name-srsly-wow
21:37:53  <isaacs>that thing
21:38:06  <isaacs>it has to be able to use a tunneling-agent module as well, to support proxying
21:38:16  <isaacs>but really, that's all that the npm http agent needs to do
21:38:35  <isaacs>requests need to be transparently cached, and that caching has to be not registry-specific, and it has to be proxy-savvy
21:38:45  <Domenic_>isaacs: yeah I guess if it's as decoupled as "plugin in a tunnelling-plus-caching agent," that's a really nice place to be.
21:38:48  <isaacs>and really, i think that's a worthwhile module *in general*
21:39:12  <isaacs>then npm-fetch can just have a way to say "Use this here agent thingie"
21:39:21  <isaacs>and or build on top of it, whatever.
21:39:31  <Domenic_>or even better something like `{ agent: require("tunnel-agent")(require("cache-agent")(http.DefaultAgent))) }`
21:40:02  <Domenic_>that feels dangerously optimistic though
21:40:22  * dguttmanjoined
21:41:46  <Raynos>what would a caching agent look like?
21:42:04  <defunctzombie>substack: I am gonna see how your latest stuff with md5 impacts the external patch so we can respond to that pull request
21:43:18  * jcrugzz_joined
21:46:07  * jcrugzzquit (Ping timeout: 264 seconds)
21:48:40  * jxsonjoined
21:49:32  <robertkowalski>at least i can say npm-fetch should not know about the implementation of the cache and types of caches should be interchangable.
21:50:18  <robertkowalski>have to leave now. timezones suck.
21:51:24  * nicholasfquit (Remote host closed the connection)
21:51:33  * jcrugzz_changed nick to jcrugzz
22:00:58  <st_luke>isaacs: NaN in JS is the best analogy to gender
22:01:14  <st_luke>assert(NaN !== NaN)
22:03:30  <isaacs>robertkowalski: we ought to get you over to us/pacific, where all programmers belong
22:03:35  <isaacs>robertkowalski: ;)
22:03:45  * wolfeidauquit (Remote host closed the connection)
22:04:56  * soldairjoined
22:05:50  <isaacs>creationix: > true > false
22:05:50  <isaacs>true
22:06:13  <isaacs>creationix: booleans don't hold the !(a>b)&&!(b>a)&&!(a==b)
22:06:39  <isaacs>creationix: only NaN, or values with identity that valueOf to NaN, would pass the test
22:06:53  <isaacs>creationix: but true valueOf()'s to 1
22:08:09  * kevino80quit (Remote host closed the connection)
22:14:04  <juliangruber>substack: just out of curiosity, there must be a way to kill a `npm start x`
22:14:45  <isaacs>Domenic_: so, i'd actually really like to rewrite request into something much much smaller and pluggable
22:15:25  <kanzure>shouldn't unit tests be provided as an additional package inside a node module, which can be independently installed? and then you can just cycle/walk through all the test modules that define the test suite of your project.
22:16:20  * kumavis_quit (Quit: kumavis_)
22:20:00  * mikolalysenkoquit (Ping timeout: 245 seconds)
22:20:32  <creationix>isaacs, right, I typoed when I was testing it in a repl, sorry for that
22:20:55  <isaacs>creationix: no problem
22:21:44  * kumavis_joined
22:21:47  <creationix>also I meant "and" not "but" when agreeing with you
22:21:52  * creationixcloses twitter
22:22:05  <creationix>obviously I need more sleep before engaging in twitter conversations
22:24:12  <creationix>heh, I close twitter and isaacs mentions me 3 times in a row making my phone go off :P
22:24:49  <creationix>isaacs, btw, you never answered my question about no.js. do you have any concrete goals with that? or are you too enveloped in node.js releases?
22:24:55  * thlorenzquit (Remote host closed the connection)
22:25:20  <isaacs>creationix: i am enveloped.
22:25:25  <creationix>I'm working on a no.js equivalent for luvit (a client is paying me for it)
22:25:26  <isaacs>creationix: no.js is a pipe-dream, let's be honest.
22:25:41  <isaacs>creationix: i'd be more likely to work on a node.c
22:25:47  <creationix>what's node.c?
22:25:52  <creationix>a better libuv or something?
22:25:54  <isaacs>creationix: node in c :)
22:26:03  <isaacs>creationix: well, so, libuv is nice, but libuv is more low-level than node.
22:26:08  * AvianFlujoined
22:26:17  <creationix>interesting
22:26:27  <isaacs>creationix: node.c would also bind to openssl, c-ares, etc., and have http server apis, etc.
22:26:45  <creationix>so sortof like https://github.com/d5/node.native, but in normal C?
22:26:50  <isaacs>creationix: the hello world in node.c would be an http server, just like in node.js
22:26:54  <isaacs>creationix: sort of, yes.
22:27:02  <creationix>that could be cool
22:27:07  <creationix>and very fast
22:27:10  <isaacs>creationix: yeah, that would be amazing.
22:27:16  <isaacs>creationix: and a delight to use.
22:27:17  <Domenic_>what problems does no.js solve.
22:27:25  <isaacs>Domenic_: the same problems that Node.js solves.
22:27:32  <Domenic_>isaacs: but worse?
22:27:40  <creationix>Domenic_, end flame wars by letting people implement their own fragmented opinions on top
22:27:53  <creationix>Domenic_, I want it so I can have more freedom in experimenting
22:28:02  * fallsemoquit (Quit: Leaving.)
22:28:06  <Domenic_>creationix: would you really be more free?
22:28:13  <creationix>yep
22:28:21  <creationix>the same way all users of libuv are free
22:28:24  <Domenic_>O_o
22:28:30  <creationix>I've seen 5 different lua bindings for libuv
22:28:32  <isaacs>Domenic_: the idea is that it would be just a module system, but use code from npm without having to pre-install, so your "http" comes from there.
22:28:40  <creationix>with wildly different async semantics
22:28:49  <Domenic_>nothing's stopping you from using a different http module today. i don't get it.
22:29:28  <creationix>Domenic_, well, the difference for me is I could create a node-fiber based platform on top of no.js and call it a no.js module and people wouldn't get upset telling it it's not the node way
22:29:38  <creationix>yes I can do that today technally
22:29:53  <creationix>but if it's a node module, you should probably use node callbacks and node streams
22:29:54  * fallsemojoined
22:30:10  <creationix>also I just like lightweight cores, they make me happy
22:30:37  <creationix>a tiny custom js interpreter coupled with libuv would make for a fun platform to program mips routers
22:30:49  <creationix>the only reason I use lua is because it's so light
22:30:55  <creationix>v8 is a beast on tiny devices
22:31:25  * fallsemoquit (Client Quit)
22:33:59  <Domenic_>custom js interpreter O_o
22:34:11  <creationix>a slow interpreter shouldn't be that hard to write
22:34:18  <creationix>especially for a subset of javascript
22:34:40  <creationix>(keep in mind in terribly bad about taking on hard challenges)
22:34:43  <Domenic_>subset of javascript O_____o
22:34:46  * yorickquit (Remote host closed the connection)
22:34:58  <creationix>Domenic_, do you really want with and arguments.callee?
22:35:12  <Domenic_>creationix: no, but I want to run existing JS code.
22:35:31  <substack>js -> c compiler!
22:35:36  <creationix>you can't run existing js code on tiny devices today
22:35:37  * mikolalysenkojoined
22:35:39  <Domenic_>creationix: that is solved by writing ES6 modules anyway, they are automatically strict and so those things are gone.
22:35:41  <creationix>a subset is better than nothing
22:35:50  <Domenic_>i guess i am not sure that is true.
22:36:09  <creationix>and by tiny I mean things like my $10 router I picked up in china
22:36:17  <creationix>1mb ram 10mb hard-drive
22:36:32  <creationix>node and v8 would never run on there
22:36:32  <jesusabdullah>back in
22:36:35  <jesusabdullah>MY day
22:36:39  <creationix>but lua can
22:36:42  <creationix>and libuv almost can
22:36:43  <jesusabdullah>that would run windows 3.11
22:36:51  <jesusabdullah>!
22:37:02  <jesusabdullah>really, libuv won't run on that? Bummer
22:37:07  <jesusabdullah>so whaddaya do creationix?
22:37:21  <creationix>there are ways to trim down libuv
22:37:25  <jesusabdullah>aha
22:37:33  <evbogue> /exit
22:37:38  * evboguequit (Quit: leaving)
22:37:44  <creationix>also you don't have to use libuv, you can write direct bindings for things like epoll
22:37:53  <creationix>it's not like you need to support windows at that level
22:39:14  <jesusabdullah>yeah I was gonna say
22:39:27  <jesusabdullah>libev maybe, or just poll/queue yo dang self
22:39:32  <creationix>jesusabdullah, also "3 megabytes (MB) total memory for version 3.11 (4 MB is recommended)"
22:39:36  <creationix>windows won't run on that
22:39:40  <jesusabdullah>weak
22:40:08  <creationix>though is is funny that node has higher requirements for a simple tcp server than windows 3.11
22:40:09  <dominictarr>Raynos: good spotting, thanks
22:40:58  <dominictarr>substack: mbrevoort Raynos spotted a mistake that I made with the scuttlebutt fix, make sure you have 5.6.6
22:42:17  <dominictarr>Raynos: aha, it would have called onUpdate twice with each message,
22:42:29  <dominictarr>but the second one would get filtered out
22:42:39  <dominictarr>at line 204
22:44:04  <st_luke>is there a good twerk ascii art
22:44:08  <st_luke>that isn't offensive
22:44:25  <dominictarr>libuvlite?
22:45:01  <Domenic_>at some point you have to stop reinventing things that already work
22:45:07  <Domenic_>even if they are not your ideal code
22:45:29  <Domenic_>i guess if you have a real problem to solve, like running on a 1 mb memory device
22:45:43  <Domenic_>but even then i question whether reinventing existing tools is the right approach vs. using ones specific for that situation
22:46:32  <dominictarr>creationix: jesusabdullah maybe a better idea: make node_modules pattern work for C
22:47:04  * mikolalysenkoquit (Ping timeout: 246 seconds)
22:51:31  * dominictarrquit (Quit: dominictarr)
22:52:05  <st_luke>npm twerk
22:53:40  <juliangruber>Raynos: just realised that thunks (as used in co) and continuables have the same api, that's awesome!
22:54:19  <juliangruber>st_luke: what does twerk mean?
22:54:28  <juliangruber>oh I see
22:54:39  <juliangruber>epic
22:55:10  <juliangruber>st_luke: do npm authors have cute girls dancing for them?
22:55:19  <st_luke>juliangruber: its a thing grown-ups do when they really like a certain piece of music
22:55:30  <juliangruber>shaking asynchronously?
22:56:13  * thlorenzjoined
22:59:43  <daleharvey>substack: cheers
22:59:57  <daleharvey>substack: problem is I need to block the next test from starting as well
23:04:18  * jcrugzzquit (Ping timeout: 264 seconds)
23:04:27  * jxsonquit (Remote host closed the connection)
23:04:36  * thlorenzquit (Ping timeout: 245 seconds)
23:04:45  <defunctzombie>anyone got a tool to dump what things in node/js are using up cpu?
23:04:58  <defunctzombie>like valgrind/cachegrind type views of stuff?
23:05:00  * jxsonjoined
23:05:05  <substack>daleharvey: just use another test for that
23:05:19  <substack>test('setup', function (t) { /* do setup things and then call t.end() */ })
23:05:38  <defunctzombie>+1 for setup tests
23:06:10  <daleharvey>after every test? (this is setup / teardown)
23:06:11  * ednapiranhajoined
23:07:03  <substack>daleharvey: what are you doing?
23:07:04  * jxsonquit (Remote host closed the connection)
23:07:08  <substack>it sounds like you're doing something weird
23:07:36  * jxsonjoined
23:07:57  * ednapiranhaquit (Remote host closed the connection)
23:08:21  <daleharvey>setup and teardown for tests is pretty normal, I want to make sure my tests run well isolated, and clean themselves up
23:09:22  <daleharvey>but its fine, I got browserify working so I can just use mocha now, I was mostly avoiding it because its browser runner sucked, but I should be able to just browserify it all
23:12:45  <juliangruber>isaacs: trololol https://npmjs.org/package/is-type
23:17:05  <substack>daleharvey: running mocha in browsers is still weird
23:17:27  <defunctzombie>daleharvey: use zuul for mocha in the browser
23:17:43  <defunctzombie>it will handle the browser stuff for you so you can just write the tests
23:18:07  <substack>also: mocha sucks
23:18:19  <defunctzombie>meh
23:18:22  <defunctzombie>mocha tdd is fine
23:18:27  <substack>globals everywhere, added at runtime!
23:18:34  <substack>and you can't just node test.js
23:18:45  <defunctzombie>whatever.. haha.. as long as they let me write simple asserts
23:18:56  <defunctzombie>and stay out of my way
23:19:45  <daleharvey>at this point I am happy with tape, I just need the ability to do teardown, take a pr for that and any suggestions on a decent api for it?
23:20:11  <substack>daleharvey: you can just write a function for that
23:20:13  <substack>tape is just callbacks
23:20:16  <substack>go wild
23:20:36  <substack>you don't need a special api to do teardown/setup
23:20:50  <substack>you only need that with shit libraries like jasmine that are super fragile
23:20:53  <daleharvey>how would I block the next test from running?
23:21:06  <guybrush>why not just test(name,function(cb){})
23:21:12  <substack>daleharvey: the next test only runs when the current one is finished
23:21:47  <substack>guybrush: that's not necessary
23:21:58  <daleharvey>sure, and I want t.end called from the test
23:22:03  <daleharvey>http://pastebin.mozilla.org/2920840 is the current code
23:22:48  <daleharvey>so the test has finished, I can wrap the test and call teardown once it ends, but its gonna be running the next test at the same time
23:22:49  <guybrush>anyway nowadays i try to switch from mocha to tape :p
23:23:09  <substack>function withSetup (name, cb) { test('setup', function (t) { /* ... */ }); test(name, cb); test('teardown', function (t) { /* ... */ }) }
23:23:17  <guybrush>long time i was on the mocha-train, now i felt some pain with all the --grep and mocha(1) fuck
23:23:28  <guybrush>had to get hurt first to learn the lesson
23:23:34  <substack>then just call withSetup(name, cb) instead of test(name, cb)
23:23:52  <daleharvey>hmm, that could work
23:29:27  <daleharvey>it does work, with async setup and teardown too :) only annoying thing now is the extra reporting, but I can live with that
23:30:33  <substack>you can use the tap runner for more compressed output
23:30:46  <substack>npm install -g tap; tap test/*.js
23:30:47  * thlorenzjoined
23:31:17  <juliangruber>daleharvey: tap is less semantic but way more hackable than mocha, that's the tradeoff
23:32:07  <daleharvey>well I just meant the setup and teardown tests being reported as tests - http://pastebin.mozilla.org/2920857
23:32:15  * vitorpachecoquit (Ping timeout: 276 seconds)
23:32:54  <substack>yeah, that's the downside to that approach
23:33:04  <juliangruber>if nothing can go wrong in setup/teardown, a custom wrapper as substack mentioned should be fine
23:33:12  <substack>but the upside is that it doesn't require any custom api support and is much more flexible as a result
23:34:26  * jcrugzzjoined
23:35:05  <juliangruber>yeah, with mocha it's like "don't fuck with the system"
23:36:52  * vitorpachecojoined
23:39:59  <daleharvey>if only we had some magic way of writing code that made sure it had run before the next thing runs :P
23:40:37  * thlorenzquit (Remote host closed the connection)
23:44:33  * timoxleyjoined
23:45:44  * AvianFluquit (Remote host closed the connection)
23:45:50  * ralphtheninjaquit (Read error: Operation timed out)
23:45:58  * ralphtheninjajoined
23:46:23  * coderzachquit (Quit: coderzach)
23:47:28  * timoxleyquit (Remote host closed the connection)
23:52:56  * mikolalysenkojoined
23:56:57  * st_lukequit (Remote host closed the connection)
23:57:50  * mikolalysenkoquit (Ping timeout: 256 seconds)