00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:03:18  * jxsonquit (Remote host closed the connection)
00:06:41  * jxsonjoined
00:10:23  * eugenewarejoined
00:12:38  <DTrejo>has anyone made an API library where you 1) write a json blog to describe your REST api, including types of parameters (for validation) 2) start a server which spins up routes and validators for everything in the blog 3) spits out a client-side javascript API client
00:12:49  <DTrejo>*the blob
00:13:03  <DTrejo>4) also a server-side javascript API client cause why not
00:13:18  <DTrejo>google does this with their API discovery stuff
00:13:54  * jxsonquit (Remote host closed the connection)
00:14:29  * jxsonjoined
00:15:10  * eugenewarequit (Ping timeout: 252 seconds)
00:18:13  <DTrejo>ogd ^ i feel like you would appreciate something like this
00:18:29  * AvianFluquit (Ping timeout: 240 seconds)
00:18:53  * jxsonquit (Ping timeout: 252 seconds)
00:19:31  <ogd>DTrejo: maybe https://github.com/sballesteros has done that
00:20:37  <DTrejo>oh and you could also write api docs with it
00:22:02  <DTrejo>hmm didnt see it in his repo list
00:23:08  * wolfeidaujoined
00:23:53  * wolfeidauquit (Remote host closed the connection)
00:24:29  * wolfeidaujoined
00:24:53  <grncdr>DTrejo: I've done parts of it in the past
00:25:17  <grncdr>in particular, lazorse and lazorse-schemas was all about that kind of thing
00:25:42  <grncdr>slightly different though, as it was designed around writing the JSON blobs inline in the source
00:26:39  <grncdr>so you would write JavaScript, defining route patterns with URI-templates and payload/response schemas with JSON-schema, then the API server could be introspected for all the information
00:26:42  <DTrejo>whats your github?
00:26:49  <DTrejo>oh nvm i can google the projcet names
00:27:00  <grncdr>https://npm.im/lazorse
00:27:09  <grncdr>and https://npm.im/lazorse-schemas I think
00:27:14  <grncdr>I haven't actually used it in ages
00:27:42  <DTrejo>is that your drawing? :0
00:27:44  <grncdr>it was very much a learn node → right a webframework
00:27:49  <grncdr>no it's substacks!
00:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 22]
00:27:59  <DTrejo>hehe i thought so
00:29:30  <DTrejo>guess what...
00:29:42  <grncdr>there's a bunch of things that do this though !
00:29:46  <grncdr>what?
00:29:58  <DTrejo>if one were to match your discovery document with the format that google uses, then one could have a node, ruby, java clients out of the box for your API
00:30:14  <DTrejo>and maybe also need to fork the google clients to lookup the discovery doc from your server
00:30:18  <DTrejo>thats the only catch
00:30:27  <grncdr>hm, that would be nice
00:30:33  <grncdr>I wrote a node client
00:30:38  <grncdr>that could be browserified
00:30:52  <grncdr>and a PHP and python one that I don't think were ever open sourced
00:31:27  <DTrejo>mm
00:31:29  <DTrejo>cool
00:31:52  <grncdr>but yeah, there's been at least 100 different attempts at standardizing a discovery format, if I were starting again, going with a de-facto standard would be smarter
00:33:49  <grncdr>oh god, I forgot about some of the stuff I did in there
00:33:55  <grncdr>that was really not a good idea :P
00:35:45  * jcrugzzquit (Ping timeout: 252 seconds)
00:37:19  <DTrejo>hehe
00:37:35  * jcrugzzjoined
00:38:14  <DTrejo>ooh guess what else
00:38:24  <grncdr>?
00:38:50  <DTrejo>you could write a testing framework that would augment the documentation part, and it would append its examples into the docs, along with output
00:38:51  <DTrejo>lol
00:38:54  <DTrejo>going too far
00:39:32  <grncdr>https://grid.betsmartmedia.com might still be running
00:39:40  <grncdr>it did pretty much exactly that
00:41:22  <grncdr>the example requests are defined inline in the source (and can be introspected) so the integration tests ask the API for all examples, perform them, and validate the responses against the declared schema. The documentation generator does the same thing, but writes some ReStructuredText files that get included in the docs
00:41:51  <grncdr>ah, certificate warning
00:43:05  <grncdr>http works, but yeah the toolchain for this stuff was a bit hairy
00:43:29  <grncdr>like, I was writing most of it as I needed it, so it wasn't really what you'd call "robust"
00:53:45  * eugenewarejoined
00:58:49  * eugenewarequit (Ping timeout: 272 seconds)
01:01:08  * jcrugzzquit (Read error: Connection reset by peer)
01:02:15  * yorickquit (Remote host closed the connection)
01:02:57  <DTrejo>cool
01:03:03  <Raynos>DTrejo: i wrote something like that
01:03:14  <DTrejo>yeah, one of those things where you only see the pattern after you've written everything
01:03:17  <Raynos>My examples were executable and outputted tap
01:03:26  <Raynos>and i had a thing to cp my examples into my readme
01:03:31  <DTrejo>nice
01:03:33  <Raynos>then i decided i was being silly
01:03:37  <DTrejo>haha
01:03:39  <DTrejo>aw
01:03:50  * tilgovijoined
01:06:14  * dguttmanjoined
01:12:08  <grncdr>Raynos: I've been doing it the other way around
01:12:40  <grncdr>for really small modules, I write the tests in the README synopsis, and use markdown-code-blocks to pull them out and pipe them into node
01:12:59  <grncdr>so my test script is "markdown-code-blocks -t javascript < README.md | node"
01:13:40  <grncdr>this is the largest example I have of it: https://github.com/grncdr/js-set-object-path
01:13:50  <grncdr>so far I like it
01:14:55  <grncdr>this one too: https://github.com/grncdr/assert-in-order
01:15:03  * jxsonjoined
01:15:26  * eugenewarejoined
01:16:08  <grncdr>only downside is I can't get coverage data out of it (afaik)
01:16:42  * wolfeidauquit (Remote host closed the connection)
01:19:43  * jxsonquit (Ping timeout: 260 seconds)
01:20:38  * eugenewarequit (Ping timeout: 264 seconds)
01:25:54  * thlorenzjoined
01:26:39  * marcello3dquit (Remote host closed the connection)
01:26:52  * ednapiranhaquit (Quit: Leaving...)
01:27:19  * marcello3djoined
01:27:50  <rowbit>Hourly usage stats: [developer: 0, free: 11]
01:28:29  * phatedquit (Ping timeout: 240 seconds)
01:28:38  * AvianFlujoined
01:28:50  <Raynos>grncdr: thats pretty cool
01:29:11  <Raynos>grncdr: but tests are not documentation
01:29:30  * wolfeidaujoined
01:29:34  * phatedjoined
01:31:29  * marcello3dquit (Ping timeout: 252 seconds)
01:37:08  * eugenewarejoined
01:39:33  * jxsonjoined
01:41:39  * eugenewarequit (Ping timeout: 252 seconds)
01:43:54  <paul_irish>thlorenz, defunctzombie: https://code.google.com/p/chromium/issues/detail?id=337909 fyi. saw you talking about it before
01:44:40  <thlorenz>paul_irish: ah, interesting didn't even consider that a bug
01:45:19  <paul_irish>seems good though... your build script yells at you because jshint found a problem in balls.js:18:32
01:45:25  <thlorenz>since it only makes sense to select a line, so in zuul we just copy the file:line of the stack trace (omitting the column) which you can then open
01:45:27  <paul_irish>nice to jump right into it in chrome
01:46:03  <paul_irish>aye. i still dont really understand how zuul works. would love a demo sometime :)
01:46:44  <thlorenz>paul_irish: oh yeah, I can shoot a quick youtube thing but also defunctzombie and I are planning to give a talk about it sometime here at a local meetup (NYC)
01:47:12  <paul_irish>niice
01:47:58  <thlorenz>paul_irish: I'll cc you if I get the video done and tweet about it (just an ultra short demo showing the stacktrace features)
01:51:33  * dguttmanquit (Ping timeout: 252 seconds)
01:52:18  * dguttmanjoined
01:52:18  <paul_irish>that'd be rad :)
01:55:13  * jxsonquit (Remote host closed the connection)
02:02:06  * thealphanerdquit (Quit: thealphanerd)
02:03:32  * ferossquit (Quit: feross)
02:03:32  * feross_changed nick to feross
02:03:51  * feross_joined
02:07:55  <grncdr>Raynos: I agree about tests not being documentation. That first example in particular is quite opaque.
02:08:16  * feross_quit (Client Quit)
02:08:34  * feross_joined
02:08:49  <grncdr>however, it's possible to interleave other content between the code blocks in the markdown without affecting the functionality, so I think it's my lack of attention that's flawed rather than the methodology
02:09:01  <grncdr>thlorenz: do you use a mac?
02:09:18  <thlorenz>grncdr: yes
02:09:42  <grncdr>do you have issues with phantomjs & browser-launch hanging around after tests finish?
02:09:48  <grncdr>* browser-launcher
02:10:08  <thlorenz>not sure what browser-launcher you are talking about
02:10:23  <grncdr>hm, the one that testling uses I would guess...
02:10:28  <grncdr>so might not be your problem
02:10:34  <thlorenz>ah, ok I use testling -x open
02:10:35  <grncdr>I thought zuul et al used the same thing
02:10:42  <grncdr>ah
02:10:58  <thlorenz>zuul doesn't launch browsers, it gives you a route in your terminal
02:11:07  <thlorenz>unless you specify --phantom
02:11:09  * DTrejoquit (Remote host closed the connection)
02:11:32  <thlorenz>browser tests are done via saucelabs mostly (to get all the different ones)
02:16:45  * dguttmanquit (Quit: dguttman)
02:20:31  * eugenewarejoined
02:24:16  <defunctzombie>grncdr: I think the open module is better than browser-launcher tho not sure
02:24:18  * ferossquit (Quit: feross)
02:24:19  * feross_changed nick to feross
02:25:31  * eugenewarequit (Ping timeout: 260 seconds)
02:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 35]
02:42:13  * eugenewarejoined
02:42:52  <defunctzombie>thlorenz: making a zuul walkthrough could be cool
02:43:20  * coderzachquit (Remote host closed the connection)
02:43:23  <thlorenz>defunctzombie: yeah, I'd still split it up into two parts
02:43:30  <thlorenz>A) how it works locally
02:43:37  <thlorenz>B) how it works with saucelabs
02:43:40  <defunctzombie>yea
02:43:49  <thlorenz>I can do A, you know way more about B
02:44:11  <defunctzombie>haha
02:44:13  <defunctzombie>yes
02:45:52  * coderzac_joined
02:47:01  * eugenewarequit (Ping timeout: 252 seconds)
02:47:08  * DTrejojoined
03:03:55  * eugenewarejoined
03:09:17  * eugenewarequit (Ping timeout: 272 seconds)
03:12:34  * tilgoviquit (Remote host closed the connection)
03:21:48  <rvagg>substack: is there anything we can do to replace stream-browserify with readable-stream for browserify? or perhaps just turn it in to a wrapper?
03:21:58  <rvagg>substack: what's the actual problem with readable-stream that stream-browserify is required?
03:22:30  * rvaggis on a mission to make require('stream') go away completely
03:22:57  <jesusabdullah>weirdo
03:23:41  <rvagg>use require('readable-stream') everywhere, get compatibility with older versions of Node, get stability in which version of streams you're using (streams2 = 1.0.x, streams3 = 1.1.x) no matter what version of node
03:23:51  <rvagg>require('stream') should be for node core cruft only
03:24:22  * funkytekjoined
03:24:54  <feross>rvagg: does streams3 change things in a non backwards compatible way?
03:26:20  <feross>(in a meaningful way)
03:27:51  <rowbit>Hourly usage stats: [developer: 2, free: 27]
03:28:03  * coderzac_quit (Remote host closed the connection)
03:31:59  * nfroidurequit (Ping timeout: 240 seconds)
03:44:16  * nfroidurejoined
03:45:23  * phatedquit (Remote host closed the connection)
03:47:17  * eugenewarejoined
03:51:56  * eugenewarequit (Ping timeout: 252 seconds)
03:52:07  <rvagg>feross: it's supposed to better support classic streams, make the whole 'data' event more "first class", but I've had some compatibility issues so I don't use readable-stream@1.1.x, only 1.0 atm, will wait for streams3 to settle more
03:52:29  <rvagg>unfortunately, most people who use readable-stream just jump in on @latest and get 1.1, which IMO is a mistake atm
03:52:46  <rvagg>we'll have the same thing when we go post-1.2 and have readable-stream@1.2.x and @1.3.x
03:54:41  <feross>rvagg: one thing that sucks about readable-stream is that it balloons browserify bundle sizes for some reason
03:54:57  <feross>if you require('stream') you get a much smaller bundle size
03:55:17  <rvagg>feross: yeah cause that's stream-browserify, I'd like to know what the difference is and what we can do about it to make it betterer
03:55:31  <rvagg>cause readable-stream is now kept up-to-date with each node release
03:56:21  <feross>$ browserify -r readable-stream | wc -c
03:56:22  <feross> 234437
03:56:26  <feross>$ browserify -r stream | wc -c
03:56:26  <feross> 106574
03:56:33  <rvagg>feross: try 1.0.x
03:56:40  <rvagg>it doesn't have core-util-is as a dependency
03:57:13  <feross>same thing
03:57:14  <feross>$ browserify -r readable-stream | wc -c
03:57:14  <feross> 239716
03:57:33  <feross>^ that was with readable-stream@1.0.25
03:57:43  <feross>core-util-is is extremely small
03:57:54  <rvagg>mm, so what's up with that? why does that happen if stream-browserify is just a "copy" of node core streams?
03:58:23  <feross>haven't investigated too deeply, but i can take a look now
03:59:34  <rvagg>line counts are very similar in stream-browserify/*.js and readable-stream/*.js
04:01:04  <substack>rvagg: because it has been optimized to not require all the files that readable-stream or core streams include
04:01:25  <substack>it's also been very carefully tuned to work in all browsers
04:02:04  <rvagg>substack: do you have a record of the changes? we could push them back in to readable-stream
04:02:10  <rvagg>possibly
04:02:15  <rvagg>as long as the core streams tests still pass
04:03:39  <rvagg>otherwise there's just going to be a continued fragmentation of 'stream' vs 'readable-stream' and the various versions thereof
04:03:59  <feross>rvagg: i just noticed something that def isn't helping with the bundle size of readable-stream
04:04:07  <feross>the entire Buffer shim is getting included twice
04:04:43  <feross>that's about 35KB that could be eliminated right there
04:05:13  <rvagg>feross: so what's the answer to that? var Buffer = require('buffer')?
04:05:16  <feross>i recall there being some weirdness about just using the global Buffer vs require('buffer').Buffer causing the shim to get inserted twice
04:05:24  <feross>i'm not 100% sure though, substack?
04:05:32  <rvagg>string_decoder is doing that
04:05:44  <rvagg>I thought about doing it in readable-stream but wasn't sure what the reasoning was for it
04:06:03  <feross>this seems like something that should just be fixed in browserify
04:06:05  <substack>I don't want to regress over all the patches that have gone into stream-browserify
04:06:50  <feross>substack: any reason we can't set the global Buffer and require('buffer').Buffer to point to the same required bundle?
04:07:01  <feross>to save 35KB of bloat
04:08:59  * eugenewarejoined
04:09:40  <rvagg>it just seems to me that this is a fairly vital part of the node ecosystem and browserify can't live up to its promised ability to allow node development in the browser without some kind of special treatment
04:09:45  <rvagg>ignoring it is futile
04:09:59  <rvagg>it'
04:10:11  <rvagg>it'll just lead to bloat for people who otherwise don't know what the problem is
04:10:13  * funkytekquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
04:12:09  <rvagg>not to mention compatibility problems: https://github.com/substack/tap-parser/pull/9
04:12:17  <rvagg>i.e. faucet is completely unusable on node 0.8
04:13:56  * eugenewarequit (Ping timeout: 252 seconds)
04:17:27  <feross>rvagg: porting all the browser fixes from stream-browserify into readable-stream and getting bundle size down seems worthwhile regardless of what the browserify uses as default
04:17:43  <feross>since lots of modules require readable-stream directly
04:25:35  <feross>rvagg: why does _stream_writable.js have this line:
04:25:37  <feross>var Stream = require('stream');
04:26:02  <feross>that will make browserify include stream-browserify in the bundle
04:26:11  <rvagg>feross: since ReadableStream overwrites everything important I believe that's there so that instanceof will still work
04:26:24  <feross>yo dawg, i herd you like streams so here's TWO implementations in ur bundle!
04:26:41  <rvagg>feross: do you think that's the core problem?
04:27:16  <feross>still looking into it, but yeah i mean that will make it include a huge 106KB stream implementation that isn't needed
04:27:26  <rvagg>it means that regardless of whether you use core-streams or different versions of readable-stream you still end up with objects with a consistent prototype chain
04:27:50  <rowbit>Hourly usage stats: [developer: 0, free: 27]
04:28:36  <rvagg>isaacs: can you sanity check that statement? readable-stream uses require('stream') just to use core-streams as a base class purely so `instanceof` will work across all stream implementations?
04:28:49  * coderzachjoined
04:29:12  <feross>it looks like its using some of the implementation too
04:29:32  <feross>rvagg: in the Writable constructor I see Stream.call(this);
04:29:41  <feross>where var Stream = require('stream');
04:30:01  <rvagg>feross: all that does is EE.call(this)
04:30:05  <rvagg>I guess there's that ..
04:30:32  <feross>that seems like it ties readable-stream to potential future breaking changes in node core
04:30:42  * eugenewarejoined
04:30:43  <feross>why not move the EE.call(this) directly into the source
04:30:45  <rvagg>otherwise 'stream' is just .pipe() which is re-implemented
04:31:06  <rvagg>feross: for that `instanceof` property, there's no Stream.isStream() like there is Buffer.isBuffer()
04:31:38  <rvagg>`foo instanceof Stream` should always work regardless of using core streams or readable-stream@1.0 or 1.1
04:31:44  <feross>rvagg: yeah, that seems important. still thinking about that.
04:31:46  <rvagg>across 0.8, 0.10 and 0.11
04:31:59  <feross>we broke that for Buffers because we're instanceof Uint8Array
04:32:07  <feross>(in the name of performance)
04:32:27  <feross>but at least there's Buffer.isBuffer()
04:33:53  * coderzachquit (Ping timeout: 272 seconds)
04:35:24  * eugenewarequit (Ping timeout: 252 seconds)
04:36:33  <rvagg>ideally browserify would be smart about this and treat readable-stream as a special case
04:37:28  * wolfeidauquit (Remote host closed the connection)
04:38:33  <substack>rvagg: special casing userland libraries seems completely antithetical to the reason for userland libs in the first place
04:38:54  <substack>it massively increases the coordination costs and opens the doors to *any* library that is misbehaving
04:38:54  <rvagg>substack: then do away with require('stream') and make people use the user-land version of it
04:38:55  * DTrejoquit (Remote host closed the connection)
04:39:00  <substack>and I don't want browserify to take on that cause
04:39:03  <substack>the scope creep is too great
04:39:18  <rvagg>I agree, but the fact that streams are in core screws this up royaly
04:39:23  <substack>rvagg: that's what the browser field is for
04:39:44  <rvagg>for special casing you mean?
04:40:20  <rvagg>stream-browserify exists on an island, I don't imagine you pull in upstream patches from core, there's no way to try streams3 out with it
04:41:51  <substack>readable-stream has different priorities from stream-browserify
04:42:15  <substack>stream-browserify is built for stability and browser compatibility
04:42:24  <substack>and file size minimization
04:42:31  <rvagg>readable-stream exists for stability too, that's moot
04:42:38  <substack>those are things that would regress very fast in readable-stream
04:42:41  <substack>without a lot of tooling
04:42:42  <rvagg>browser compatibility, we can probably fix that in readable-stream
04:43:28  <feross>i think the file size problem with 'readable-stream' is only there because it ALSO has to include stream-browserify, effectively doubling its size
04:43:43  <rvagg>so what's a library like this to do? https://github.com/maxogden/csv-write-stream
04:43:57  <rvagg>it'll pull in readable-stream to do its thing, but it's getting bloat too
04:44:12  <substack>I spent like a week fixing very subtle browser issues with stream-browserify. I don't look forward to duplicating all that work.
04:44:31  <rvagg>substack: but you're going to have to do it anyway when 0.12 is released
04:44:45  <rvagg>I've tried messing with the 'browser' package.json property without much success, I don't imagine there are many others out there who have the smallest clue
04:45:15  <rvagg>https://github.com/isaacs/readable-stream/blob/master/build/files.js
04:45:35  <rvagg>we have the capabilities to fix browser compatibility issues if they aren't going to impact too much on perf or are too complex
04:49:10  <rvagg>looks like just some changes for process.nextTick/setImmediate, forEach and indexOf in there when I compare equivilant versions of stream-browserify and readable-stream@1.0
04:49:54  * coderzachjoined
04:51:00  <substack>rvagg: if you can get all those fixes into readable-stream and also get readable-stream on testling-ci so I can just swap stream-browserify for readable-stream
04:52:07  <feross>rvagg, substack: i can help with this testing & debugging old browsers
04:52:24  * eugenewarejoined
04:52:24  <feross>i got buffers working down to ie6 recently :)
04:53:04  <rvagg>we'll see what we can do without making too big a footprint
04:53:46  <feross>i'm in favor of readable-stream becoming default for 'stream'. that will make the file size of everything that includes 'readable-stream' (which is many modules these days) much, much smaller
04:54:10  * coderzachquit (Ping timeout: 245 seconds)
04:56:16  * jxsonjoined
04:56:19  <guybrush>i wonder if there will be a stream4 some day :D
04:56:48  * eugenewarequit (Ping timeout: 245 seconds)
04:56:58  <guybrush>also i fear promises and generator stuff, basically i dont even understand code with that stuff in it :/
04:59:19  <guybrush>also it looks ugly haha
05:00:12  <rvagg>the day that stuff becomes mainstream Node, 1/2 the people in this channel will probably be hacking on some new platform anyway
05:00:59  * jxsonquit (Ping timeout: 240 seconds)
05:02:09  <grncdr>Node.vb
05:06:20  <guybrush>vertx! nodejx! wow! such crazy much spread so not compatible with node-eco cool
05:07:02  <grncdr>hah, I wanted to like vertx
05:08:29  <grncdr>like, the idea of a reliable global event bus tying together tiny little modules implemented in any of 5 languages
05:08:34  <grncdr>that *sounds* cool
05:08:34  <guybrush>it hasnt 'node' in its name, so its only moderate cool
05:09:01  <grncdr>but every time I go to JVM land I regret it :|
05:09:44  <guybrush>i cant see why anyone would like to program in java
05:10:09  <grncdr>different strokes
05:10:22  <grncdr>there are people who say the same about JavaScript
05:10:25  <grncdr>:D
05:10:32  <guybrush>its only my opinion for sure and there are lots of cool and awesome javastuff
05:11:09  <guybrush>i only enjoy javascript c and lua
05:11:38  <guybrush>but im really only able to build something real in js :p
05:12:54  <feross>rvagg: when i do "node build.js <version>" what version from 0.10.x should i use?
05:12:54  <guybrush>though im really looking forward to get better with c, need to look more into thlorenz stuff
05:13:05  <rvagg>feross: ./build.js 0.10.25
05:13:19  <feross>that adds a new test, is that cool?
05:13:27  <thlorenz>guybrush: that may be a bit too soon as I'm just slowly coming out of my noobness ;)
05:13:34  <guybrush>thlorenz: why did you choose clib over dotc?
05:13:42  <rvagg>feross: oh does it? hm, mustn't have checked it in before, leave it out of the PR
05:13:43  <thlorenz>I'd suggest to read thru some of the clibs instead
05:13:49  <rvagg>I'll add it later, test should pass tho
05:14:01  <thlorenz>guybrush: dotc has problems, like it doesn't work with macros at all
05:14:07  * eugenewarejoined
05:14:18  <guybrush>but its totally plugable into npm!
05:14:22  <thlorenz>also it messes with my editor plugins like syntastic which don't understand dot.c
05:14:26  <guybrush>who nieeds macros :p
05:14:44  <thlorenz>guybrush: are you kidding? if you do pure C you're gonna need them
05:14:46  <rvagg>feross: sorry, I forgot to push my latest, I'd already published 1.0.25 with this but hadn't pushed to github
05:14:52  <rvagg>feross: rebase to latest v0.10, pushed it now
05:14:57  <feross>k
05:15:21  <thlorenz>guybrush: so for now I stuck with clib cuz it at least works, even if some parts aren't that pretty
05:15:53  <guybrush>thlorenz: cool i have to look into it more maybe
05:15:55  <thlorenz>we had a discussion in #npmalloc about this way back, you could join if you wanna talk npm modules for C
05:16:14  <thlorenz>yeah, if you come up with something that works I'll buy you a beer :)
05:18:54  * eugenewarequit (Ping timeout: 252 seconds)
05:19:06  * contrahaxquit (Quit: Sleeping)
05:19:35  <guybrush>actually i _really_ like the idea of using gh as registry, or rather just a very simple registry-api that happens to be just like gh
05:20:19  <guybrush>like tj made component
05:20:20  <rvagg>thlorenz: you should also /join #uvjs and help out with that with your new-found C skillz
05:21:02  <thlorenz>rvagg: ah didn't know that existed - have been hanging in #libuv, but most stuff there is way over my head
05:21:51  <guybrush>i like reading stuff i dont understand, whats the point of reading things you already know haha :D
05:22:03  <thlorenz>ah defunctzombie's channel he tried to recruit me before for uvjs -- gonna polish my C first though before mixing and matchin ;)
05:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 30]
05:31:32  <feross>rvagg: done!
05:31:34  <feross>https://github.com/isaacs/readable-stream/pull/75
05:37:22  * defunctzombiechanged nick to defunctzombie_zz
05:38:38  * wolfeidaujoined
05:40:48  <feross>rvagg: what's the point of the float.patch file? With the build file, you don't really need that around anymore, right?
05:41:10  <rvagg>feross: I don't know .. I haven't deleted it yet because I don't know what it's for!
05:41:16  <rvagg>I deleted some other cruft
05:41:37  <feross>i think it's just a diff of all the changes
05:41:43  <feross>rvagg: see this https://github.com/isaacs/core-util-is/commit/3b246db45e11bc208bfc10f10a16f55c4b71c45e
05:42:11  <feross>that's what i had to do for isaacs to merge my change into core-util-is
05:42:17  <rvagg>ah ok, so "float", do you think that's referring to "floating the code out of core"?
05:42:28  <feross>yeah probably!
05:42:52  <rvagg>mm, I should probably ditch it then
05:43:01  <feross>but it looks massively out of date for readable-stream
05:43:04  <feross>i would ditch it
05:43:17  <feross>and it's super annoying to keep it up to date. the build script approach is better
05:43:28  <feross>well, not "super annoying" maybe
05:43:36  <feross>just not useful for anything
05:44:51  * thlorenzquit (Remote host closed the connection)
05:50:47  * coderzachjoined
05:55:35  * coderzachquit (Ping timeout: 272 seconds)
05:57:30  * eugenewarejoined
06:02:38  * eugenewarequit (Ping timeout: 264 seconds)
06:19:13  * eugenewarejoined
06:23:59  * eugenewarequit (Ping timeout: 240 seconds)
06:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 14]
06:29:22  * Maciek416quit (Remote host closed the connection)
06:29:23  * AvianFluquit (Remote host closed the connection)
06:37:59  * pfrazequit (Ping timeout: 260 seconds)
06:39:08  <feross>rvagg: seems like lots of the tests for readable-stream are actually testing stream instead of readable-stream
06:39:08  <feross>see: https://github.com/isaacs/readable-stream/blob/v0.10/test/simple/test-stream-pipe-event.js#L31
06:39:15  * dominictarrjoined
06:40:06  <feross>^ any idea what's up with that?
06:41:10  <jesusabdullah>https://npmjs.org/browse/keyword/sweet-macros :o
06:45:18  <rvagg>feross: I have to somewhat manually find and turn those into proper tests for readable-stream
06:45:43  <feross>rvagg: so just to confirm, they're testing nothing right now?
06:45:53  <rvagg>feross: but with respect to that, those tests probably don't even make sense here
06:46:06  <rvagg>they are just testing the plain pipe() which we have no control over
06:46:19  <rvagg>so ya, they are irrelevant atm
06:46:32  * brianloveswordsquit (Excess Flood)
06:46:44  <rvagg>feross: I'm still going through and making some of the newer tests pass with 0.8, got some failures there still but I think it's mostly related to the tests rather than the impl
06:46:50  * brianloveswordsjoined
06:47:07  <rvagg>feross: see build/test-replacements.js for some of my work converting core tests
06:47:13  <feross>yeah saw that
06:47:43  <feross>okay, another question: if we want readable-stream to become the default for require('stream') in browserify then don't we need to include the implementation for pipe() in readable-stream instead of pulling that in from core streams?
06:51:32  * coderzachjoined
06:52:11  <feross>if i understand it correctly, right now the pipe() implementation that browserify'd readable-stream uses is actually from stream-browserify!
06:52:24  <feross>STREAMS IN STREAMS
06:53:34  <feross>oh, maybe i'm being silly...
06:54:14  <rvagg>feross: we'd need to mock it out with something that just gives us the EE inheritance
06:54:29  <feross>i see this in _stream_readable.js
06:54:30  <feross> // convert to an old-style stream.
06:54:31  <rvagg>lib/_stream_readable.js overrides pipe so there's only EE left
06:54:31  <feross> stream.readable = true;
06:54:32  <feross> stream.pipe = Stream.prototype.pipe;
06:54:49  <rvagg>oh, that's interesting
06:54:54  <feross>the lines i pasted will set pipe to stream-browserify's pipe() method
06:55:09  <rvagg>which is silly since that's just a copy of readable-stream also
06:56:08  <feross>i'm a fan of very small bundle sizes, so i don't care how we do it, but i want both require('stream') and require('readable-stream') to include 100kb at most
06:56:14  * coderzachquit (Ping timeout: 252 seconds)
06:56:21  <feross>willing to help make this happen
06:57:12  <feross>i think one easy way to get started would be to make readable-stream not use require('stream') for anything except the instanceof trick
06:57:36  <feross>then next we can add more browser compat
06:58:17  <feross>then lastly, we just add a test to only require('stream') when we're not in browserify
06:58:24  <feross>or maybe use the "browser" field
06:58:30  <feross>and then i think this can become the default
06:59:04  <feross>the instanceof trick won't be necessary if BOTH 'readable-stream' and 'stream' are the same thing in the browser
06:59:38  <feross>so, then we've made the bundle size super small :)
07:00:46  <dominictarr>hmm, sounds like that might break other stuff that is expecting indexof
07:01:25  <feross>dominictarr: what do you mean?
07:01:28  <dominictarr>generally, I advise against using instanceof in node, because node_modules can break singletons
07:02:18  <dominictarr>well, if userland module is testing `x instanceof ReadableStream` it would be best if it reacted the same way in browserify as in node.js
07:02:36  <feross>it would, i think
07:03:45  <dominictarr>substack, do you have an api accessable job queue for testling?
07:04:01  <feross>currently 'readable-stream' does require('stream') internally and makes all its streams inherit from that so that when someone checks `x instance ReadableStream` it will work
07:04:38  <feross>but that means that when 'readable-stream' is browserified that TWO stream implementations get bundled and that's like ~250KB
07:04:58  <dominictarr>ah, yeah. stream2 is massive.
07:06:00  <feross>so i was suggesting that if 'readable-stream' were to be required instead of 'stream-browserify' when users do require('stream'), then we wouldn't need to include two implementations anymore
07:06:38  <feross>because then require('stream').ReadableStream would === require('readable-stream').ReadableStream
07:10:17  * dominictarrquit (Ping timeout: 252 seconds)
07:19:35  * contrahaxjoined
07:23:39  * contrahaxquit (Client Quit)
07:24:00  * eugenewarejoined
07:24:26  <feross>substack: I just fixed two small bugs in stream-browserify: https://github.com/substack/stream-browserify/pull/6
07:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 35]
07:29:15  * eugenewarequit (Ping timeout: 252 seconds)
07:37:03  * DTrejojoined
07:40:02  <rvagg>doh, I just sent 4k dogecoin to a bad address
07:40:04  <rvagg>I'm such a noob
07:40:17  <rvagg>er, 6k
07:47:22  * contrahaxjoined
07:48:14  * fotoveritequit (Quit: fotoverite)
07:52:11  * coderzachjoined
07:54:37  * contrahaxquit (Quit: Sleeping)
07:56:23  * coderzachquit (Ping timeout: 245 seconds)
08:02:37  * soldairjoined
08:07:44  * eugenewarejoined
08:12:21  * eugenewarequit (Ping timeout: 248 seconds)
08:17:23  * indexzerojoined
08:18:12  * indexzeroquit (Client Quit)
08:26:55  * soldairquit (Ping timeout: 245 seconds)
08:27:50  <rowbit>Hourly usage stats: [developer: 0, free: 30]
08:29:26  * eugenewarejoined
08:32:59  * shamaquit
08:34:26  * eugenewarequit (Ping timeout: 264 seconds)
08:40:56  <substack>https://github.com/substack/factor-bundle
08:45:31  * DTrejoquit
08:52:59  * coderzachjoined
08:57:05  * coderzachquit (Ping timeout: 245 seconds)
09:12:50  * eugenewarejoined
09:12:59  <rvagg>https://github.com/rvagg/list-stream
09:17:38  * eugenewarequit (Ping timeout: 264 seconds)
09:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 15]
09:34:32  * eugenewarejoined
09:39:02  <feross>substack/pkrumins: i just noticed the testling package on npm is still using browserify 2.x !!
09:39:04  <feross>that means that when people do `browserify test/*.js | testling -u` they will get multiple different versions of Buffer
09:39:25  * eugenewarequit (Ping timeout: 272 seconds)
09:53:45  * coderzachjoined
09:58:21  * coderzachquit (Ping timeout: 252 seconds)
10:07:38  * soldairjoined
10:17:55  * eugenewarejoined
10:21:23  * contrahaxjoined
10:22:30  * eugenewarequit (Ping timeout: 252 seconds)
10:22:45  * contrahaxquit (Client Quit)
10:25:26  * contrahaxjoined
10:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 34]
10:29:23  * Altreusquit (Changing host)
10:29:23  * Altreusjoined
10:30:00  * contrahaxquit (Ping timeout: 245 seconds)
10:33:15  * ferossquit (Quit: feross)
10:34:40  * ferossjoined
10:39:37  * eugenewarejoined
10:44:21  * eugenewarequit (Ping timeout: 265 seconds)
10:54:30  * coderzachjoined
10:54:51  * yorickjoined
10:58:43  * coderzachquit (Ping timeout: 252 seconds)
11:00:41  * contrahaxjoined
11:01:19  * eugenewarejoined
11:04:23  * contrahaxquit (Client Quit)
11:06:09  * contrahaxjoined
11:06:11  * eugenewarequit (Ping timeout: 272 seconds)
11:23:01  * eugenewarejoined
11:27:33  * eugenewarequit (Ping timeout: 248 seconds)
11:27:50  <rowbit>Hourly usage stats: [developer: 0, free: 9]
11:49:01  * fronxjoined
11:55:06  * coderzachjoined
11:59:35  * coderzachquit (Ping timeout: 245 seconds)
12:06:25  * eugenewarejoined
12:11:21  * fronxquit (Remote host closed the connection)
12:11:47  * eugenewarequit (Ping timeout: 272 seconds)
12:11:52  * fronxjoined
12:27:50  <rowbit>Hourly usage stats: [developer: 0, free: 17]
12:37:50  * fronxquit (Remote host closed the connection)
12:47:10  * fronxjoined
12:49:49  * eugenewarejoined
12:54:35  * eugenewarequit (Ping timeout: 252 seconds)
12:55:58  * coderzachjoined
13:00:08  * coderzachquit (Ping timeout: 245 seconds)
13:11:30  * eugenewarejoined
13:16:08  * fronxquit (Remote host closed the connection)
13:16:39  * eugenewarequit (Ping timeout: 272 seconds)
13:27:50  <rowbit>Hourly usage stats: [developer: 0, free: 31]
13:33:11  * eugenewarejoined
13:37:59  * eugenewarequit (Ping timeout: 260 seconds)
13:49:13  * fronxjoined
13:50:55  * dominictarrjoined
13:54:54  * eugenewarejoined
13:55:29  * fronxquit (Ping timeout: 240 seconds)
13:56:44  * coderzachjoined
13:59:33  * eugenewarequit (Ping timeout: 248 seconds)
14:01:09  * coderzachquit (Ping timeout: 248 seconds)
14:01:32  * hij1nxquit (Quit: WeeChat 0.3.2)
14:06:59  * fronxjoined
14:07:44  * contrahaxquit (Quit: Sleeping)
14:07:49  * hij1nxjoined
14:12:55  * hij1nxquit (Quit: WeeChat 0.3.2)
14:16:36  * eugenewarejoined
14:17:37  * AvianFlujoined
14:21:14  * eugenewarequit (Ping timeout: 264 seconds)
14:25:44  * defunctzombie_zzchanged nick to defunctzombie
14:27:51  <rowbit>Hourly usage stats: [developer: 0, free: 32]
14:28:31  <defunctzombie>feross: substack: pkrumins: I think auto inclusion of Buffer needs to stop
14:28:51  <defunctzombie>I know it will be a breaking change but globals are annoying to reason about and cause problems like this
14:29:59  * hij1nxjoined
14:30:04  * hij1nxquit (Client Quit)
14:30:14  <defunctzombie>we should require that buffer be used via a require()
14:31:00  * hij1nxjoined
14:31:06  * hij1nxquit (Client Quit)
14:31:25  <defunctzombie>feross: how does that mean people will get different versions of Buffer? the js has already been bundled before it gets passed to testling
14:31:31  * hij1nxjoined
14:31:40  * hij1nxquit (Client Quit)
14:32:24  * hij1nxjoined
14:32:42  <dominictarr>buffer is a global in node, and browserify mission is node in the browser.
14:36:21  * coderzachjoined
14:38:18  * eugenewarejoined
14:42:45  * eugenewarequit (Ping timeout: 252 seconds)
14:49:56  * pkruminsquit (Ping timeout: 252 seconds)
14:50:45  * rowbitquit (Ping timeout: 272 seconds)
14:56:32  * fronxquit (Remote host closed the connection)
14:58:08  * fronxjoined
14:59:34  * fronxquit (Remote host closed the connection)
14:59:46  * fronxjoined
14:59:59  * eugenewarejoined
15:04:35  * eugenewarequit (Ping timeout: 245 seconds)
15:11:19  * defunctzombiechanged nick to defunctzombie_zz
15:21:42  * eugenewarejoined
15:25:30  * fronxquit (Remote host closed the connection)
15:26:29  * eugenewarequit (Ping timeout: 248 seconds)
15:41:50  * pfrazejoined
15:44:59  * Maciek416joined
15:48:36  * fronxjoined
15:55:38  * soldairquit (Ping timeout: 245 seconds)
16:00:48  * fotoveritejoined
16:11:03  * dominictarrquit (Ping timeout: 260 seconds)
16:13:18  * dominictarrjoined
16:18:03  * thlorenzjoined
16:30:46  * mikolalysenkojoined
16:48:10  * eugenewarejoined
16:52:37  * eugenewarequit (Ping timeout: 252 seconds)
16:56:32  * hoobdeeblajoined
17:11:17  * Maciek416quit (Remote host closed the connection)
17:15:35  * brianloveswordsquit (Excess Flood)
17:16:54  * brianloveswordsjoined
17:31:50  * eugenewarejoined
17:36:23  * eugenewarequit (Ping timeout: 245 seconds)
17:37:01  * coderzachquit (Remote host closed the connection)
17:44:49  * fronxquit (Remote host closed the connection)
17:46:47  * fronxjoined
18:02:31  * fronxquit (Remote host closed the connection)
18:04:12  * marcello3djoined
18:14:15  * phatedjoined
18:15:13  * eugenewarejoined
18:15:32  * pkruminsjoined
18:15:33  * pkruminsquit (Changing host)
18:15:33  * pkruminsjoined
18:15:53  * thealphanerdjoined
18:16:00  * thealphanerdquit (Client Quit)
18:18:05  * hoobdeeblaquit (Remote host closed the connection)
18:18:23  * hoobdeeblajoined
18:20:13  * marcello3dquit (Remote host closed the connection)
18:20:23  * eugenewarequit (Ping timeout: 272 seconds)
18:20:49  * marcello3djoined
18:25:03  * marcello3dquit (Ping timeout: 252 seconds)
18:33:03  * fronxjoined
18:36:53  * eugenewarejoined
18:37:48  * coderzachjoined
18:37:57  * phatedquit (Remote host closed the connection)
18:38:00  * fronxquit (Ping timeout: 265 seconds)
18:39:16  * thlorenzquit (Remote host closed the connection)
18:41:23  * eugenewarequit (Ping timeout: 245 seconds)
18:42:13  * coderzachquit (Ping timeout: 245 seconds)
18:52:07  * hoobdeeblaquit (Remote host closed the connection)
18:52:26  * hoobdeeblajoined
18:55:25  * coderzachjoined
18:58:36  * eugenewarejoined
19:03:21  * eugenewarequit (Ping timeout: 252 seconds)
19:06:50  * mafintoshjoined
19:12:39  * thlorenzjoined
19:15:22  * thlorenzquit (Remote host closed the connection)
19:20:16  * eugenewarejoined
19:24:53  * eugenewarequit (Ping timeout: 265 seconds)
19:26:41  * phatedjoined
19:29:14  * dominictarrquit (Ping timeout: 265 seconds)
19:31:25  * marcello3djoined
19:35:33  * marcello3dquit (Ping timeout: 248 seconds)
19:36:36  * jhizzlejoined
19:41:18  * thlorenzjoined
19:41:57  * eugenewarejoined
19:44:26  * fronxjoined
19:45:18  * shamajoined
19:46:03  * fronxquit (Remote host closed the connection)
19:46:23  * eugenewarequit (Ping timeout: 245 seconds)
19:48:53  * jhizzlequit (Ping timeout: 248 seconds)
19:57:54  <thlorenz>mmalecki: so I refactored the streams to get as closely as possible to what creationix was suggesting
19:58:07  <thlorenz>this example shows, write, multi emit and pipe: https://github.com/thlorenz/sync-stream.c/blob/master/src/transform.c#L141
20:03:00  * rowbitjoined
20:03:39  * eugenewarejoined
20:07:59  * mikolalysenkoquit (Ping timeout: 240 seconds)
20:08:35  * eugenewarequit (Ping timeout: 260 seconds)
20:11:48  * mikolalysenkojoined
20:23:39  * defunctzombie_zzchanged nick to defunctzombie
20:35:01  * phatedquit (Remote host closed the connection)
20:35:33  * phatedjoined
20:39:53  * phatedquit (Ping timeout: 252 seconds)
20:48:24  * pfrazequit (Ping timeout: 252 seconds)
20:52:26  <rowbit>Hourly usage stats: [free: 33]
20:57:47  <grncdr>thlorenz: this might be more of a dependency than you want to add, but have you seen ffcall? http://www.haible.de/bruno/packages-ffcall-README.html
20:58:19  <thlorenz>grncdr: add to what ?
20:58:28  <grncdr>your C streams impl.
20:58:33  <thlorenz>ah to get closures?
20:58:36  <grncdr>yeah
20:58:41  <thlorenz>meh - don't need closures :)
20:58:53  <thlorenz>just build the right struct and you are good to go
20:59:05  <grncdr>need is too strong a word
20:59:12  <grncdr>want, on the other hand … ;)
20:59:26  <thlorenz>:) I'll keep in mind, thanks for the tip
20:59:39  <thlorenz>btw at this point I have no deps at all: https://github.com/thlorenz/sync-stream.c/tree/dev
21:00:00  <thlorenz>working on more examples and tests and wanna get some feedback from mmalecki
21:00:26  <thlorenz>possibly that transform.c needs to be just stream.c since it can be a readable/writable and a transform
21:00:33  <thlorenz>at least you can use it as either
21:01:03  <grncdr>so one thing I noticed in your example is that you assign to ->pipe
21:01:13  <grncdr>which means you can't pipe the same stream to multiple destinations...
21:01:36  <grncdr>that's probably not a common use, but it can come in handy
21:02:01  <thlorenz>grncdr: yeah, I thought about that
21:02:37  <thlorenz>it may become an array of pipes and probably I'll add an sst_pipe method to keep API simple
21:02:58  <thlorenz>if you want you can file an issue, so we can discuss these things and make sure we get it all in :)
21:03:28  <grncdr>you might also be able to write a 'tee' transform with the current API, in which case you don't need to bake it in
21:03:30  <thlorenz>grncdr: just wanna avoid taking dep on a linked list
21:04:12  <thlorenz>good idea - I was planning to do something like fs.createReadStream next, but I can look into tee after that
21:04:13  <grncdr>I don't think I'll open an issue… I'm really just a casual bikeshedder, don't have any intended use for this stuff ;)
21:04:43  <thlorenz>grncdr: that's ok, but don't think as issues as bad IMO they are just another discussion platform
21:05:00  <thlorenz>so discussion is good
21:08:41  * eugenewarejoined
21:10:12  * brianloveswordsquit (Excess Flood)
21:11:25  * brianloveswordsjoined
21:13:38  * eugenewarequit (Ping timeout: 265 seconds)
21:36:47  * coderzachquit (Remote host closed the connection)
21:42:35  * mmaleckiquit (Read error: Connection reset by peer)
21:43:11  * mmaleckijoined
21:47:28  * contrahaxjoined
21:47:45  * mikolalysenkoquit (Ping timeout: 272 seconds)
21:48:17  * coderzachjoined
21:50:58  * phatedjoined
21:51:41  * mikolalysenkojoined
21:52:05  * eugenewarejoined
21:52:26  <rowbit>Hourly usage stats: [free: 31]
21:55:39  <feross>defunctzombie: "I think auto inclusion of Buffer needs to stop" that is a bad idea. so many node modules wouldn't work!
21:56:16  <defunctzombie>feross: I think that browserify trying to make "node in the browser" actually scares away and confuses people about the actual usefulness of browserify
21:56:20  * phatedquit (Remote host closed the connection)
21:56:24  <defunctzombie>which is to package commonjs modules
21:56:34  <defunctzombie>so you can write JS code in a sane and maintainable way
21:56:36  * eugenewarequit (Ping timeout: 252 seconds)
21:57:18  <feross>hmm, but one thing that makes browserify powerful *in practice* is that so many npm modules already work with it out of the box
21:57:22  <defunctzombie>maybe there is a simpler version of browserify that can exist that doesn't do some of the nonsense with making node stuff work
21:57:48  <defunctzombie>feross: unless those modules are tested in browsers they do not already work
21:57:59  <defunctzombie>and yes, modules do work, but most would still continue to work
21:58:30  <feross>defunctzombie: also for the record, Buffer is not ever "auto included"
21:58:36  <defunctzombie>in practice what makes it powerful for me is as an awesome js package tool... but everyone has their own use case :)
21:58:40  <feross>it's only included when it's used and thus actually needed :)
21:58:47  <defunctzombie>right
21:58:59  * contrahaxquit (Quit: Sleeping)
21:59:02  <defunctzombie>the fact that it is a global is dumb
21:59:10  <feross>yeah, completely agree
21:59:24  <feross>it should have been "var Buffer = require('buffer')"
21:59:30  <feross>easy, simple
21:59:49  <defunctzombie>yea
21:59:55  <defunctzombie>why have a module system and then not use it rofl
22:00:19  <feross>bad JS habits leftover from the bad old days
22:05:32  <feross>substack: is it easy to make 'insert-module-globals' insert "var Buffer = require('buffer').Buffer" instead of dumping another copy of Buffer into the bundle?
22:05:37  <feross>so only one Buffer is ever included
22:05:56  <feross>and we don't have to go around changing every module to use "var Buffer = require('buffer').Buffer" to save byets
22:08:53  <feross>also, substack: testling is broke on OS X
22:09:00  <feross>substack: I sent you a PR to fix it: https://github.com/substack/testling/pull/64
22:13:30  * phatedjoined
22:16:23  * ins0mniaquit (Ping timeout: 245 seconds)
22:18:58  * thealphanerdjoined
22:43:15  <grncdr>feross: you could probably test that change to insert-module-globals using the API it already exposes
22:44:05  <grncdr>(I was curious about how difficult it would be, and it doesn't look very hard to modify the behaviour of insert-module-globals...
22:45:00  <feross>cool! i don't have time to look at it right this moment, but i think this would be really worthwhile!
22:45:25  <grncdr>I might just do it anyways
22:45:36  <grncdr>kind of bored with what I was working on right now ;)
22:45:52  <feross>haha, i know the feeling :)
22:45:55  <grncdr>I wonder if this has been discussed before though!
22:46:03  <feross>yeah, that's why i tried pinging substack earlier
22:46:19  <feross>seems obvious enough that i guessed there was some reason we're not thinking of
22:52:26  <rowbit>Hourly usage stats: [free: 26]
22:52:57  <feross>one other bad thing with the current insert-module-globals behavior that i just noticed: native-buffer-browserify
22:53:07  <grncdr>reading it more closely and it seems like this is what it already does...
22:53:11  <feross>native-buffer-browserify's deps are getting included twice
22:53:17  * AvianFluquit (Remote host closed the connection)
22:54:27  <grncdr>https://github.com/substack/insert-module-globals/blob/master/index.js#L103-L106
22:55:33  <feross>yeah, but that causes require('__browserify_Buffer') to get inserted into the source
22:55:37  <feross>which is a different copy of Buffer
22:55:43  <grncdr>than which copy?
22:55:45  <feross>require('buffer')
22:56:08  <feross>some people do "var Buffer = require('buffer').Buffer" and some just use the Buffer global
22:56:12  <grncdr>but how can you know that require('buffer') is there?
22:56:24  <feross>you can't easily i think
22:56:58  <feross>which is why adding "var Buffer = require('buffer').Buffer" to files that use the Buffer global is preferable
22:57:12  <feross>then i think browserify would just include the one 'buffer' module
22:57:22  * eugenewarejoined
22:57:26  * phatedquit (Remote host closed the connection)
22:57:41  * contrahaxjoined
22:57:58  * phatedjoined
23:01:47  * eugenewarequit (Ping timeout: 252 seconds)
23:02:51  * phatedquit (Ping timeout: 272 seconds)
23:03:07  * mikolalysenkoquit (Ping timeout: 260 seconds)
23:04:22  <grncdr>ah, I'm starting to understand more :)
23:09:18  * indexzerojoined
23:15:27  * defunctzombiechanged nick to defunctzombie_zz
23:18:49  * eugenewarejoined
23:23:25  * eugenewarequit (Ping timeout: 252 seconds)
23:26:06  * phatedjoined
23:29:11  * soldairjoined
23:38:50  * mafintoshquit (Quit: Leaving...)
23:39:46  * mafintoshjoined
23:40:29  * eugenewarejoined
23:41:24  * coderzachquit (Remote host closed the connection)
23:44:59  * eugenewarequit (Ping timeout: 240 seconds)
23:48:50  * i_m_caquit (Ping timeout: 264 seconds)
23:52:26  <rowbit>Hourly usage stats: [free: 17]
23:53:52  * thlorenzquit (Remote host closed the connection)
23:56:58  * mafintoshquit (Quit: Leaving...)