00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:11  * damonoehlmanjoined
00:10:27  * mikolalysenkoquit (Ping timeout: 256 seconds)
00:12:46  * fallsemojoined
00:15:50  * cpettittjoined
00:21:51  * mikolalysenkojoined
00:34:44  * calvinfoquit (Quit: Leaving.)
00:40:40  * i_m_cajoined
00:46:47  <defunctzombie>thlorenz: I need to take a closer look at the changeset, but agree that it should be a part of browserify
00:46:59  <defunctzombie>thlorenz: this is something I would expect from my browser bundler tool
00:48:44  <defunctzombie>thlorenz: I don't like that it manages the cache
00:49:00  <defunctzombie>something feels like that should be an option to it
00:49:10  <defunctzombie>so you could use disjoint versions of it
00:49:15  <defunctzombie>in different bundles or whatnot
00:49:18  * fallsemoquit (Ping timeout: 264 seconds)
00:49:29  <defunctzombie>my tendency is against globals for modules like this
00:49:37  <defunctzombie>I don't think they should be doing the caching layer
00:50:32  <defunctzombie>thlorenz: also, dedupe does not belong in browser resolve imho
00:50:33  * mikolalysenkoquit (Ping timeout: 245 seconds)
00:50:47  <defunctzombie>thlorenz: it has nothing to do with that module, that module is only about resolving modules via support of the "browser" field in package.json
00:50:51  <defunctzombie>dedupe is a higher level function
00:51:16  <defunctzombie>that is my feedback :)
00:52:11  <defunctzombie>substack: thlorenz: on an unrelated note, I personally think you can do more interesting things at the file level
00:52:20  <defunctzombie>I think you can md5 every source file
00:52:47  <defunctzombie>and check that stuff too, so this way even if some parts of a module change but other parts don't, you get more reusability
00:53:16  * fallsemojoined
00:53:57  * i_m_caquit (Ping timeout: 248 seconds)
00:54:51  * mirkokieferquit (Quit: mirkokiefer)
00:55:41  * kumavis_quit (Quit: kumavis_)
00:56:25  * calvinfojoined
01:02:22  * mikolalysenkojoined
01:05:22  * cpettittquit (Quit: cpettitt)
01:07:54  * mikolalysenkoquit (Ping timeout: 264 seconds)
01:15:12  * coderzachquit (Quit: coderzach)
01:18:14  * gwenbelljoined
01:18:21  * evboguejoined
01:19:26  <thlorenz>defunctzombie: true, but a file may be identical with relative requires, but they end up meaning something different, so deduping on package level is best IMHO
01:19:55  <thlorenz>I tried around with this a bit until coming to this conclusion
01:20:42  <thlorenz>defunctzombie: not sure which managed cache you are referring to - the one in browser-dedupe?
01:20:55  * ins0mniaquit (Ping timeout: 241 seconds)
01:21:07  * evboguequit (Client Quit)
01:21:14  * mikolalysenkojoined
01:21:19  <thlorenz>also where else than in browser-resolve would I apply the dedupe wrap?
01:22:23  * cpettittjoined
01:23:51  <thlorenz>defunctzombie: I guess I could try to just do it in browserify itself
01:24:34  <thlorenz>so I'll get the missing tests in (browser-dedupe and browserify) and try to do it without changing browser-resolve
01:28:00  * gwenbellquit (Quit: Lost terminal)
01:30:04  <cpettitt>Is the fs module not supported with testing? I have a test that uses it, but the object I get from require("fs") is always empty when run from testling
01:41:07  * kriskowaljoined
01:41:15  * fallsemoquit (Ping timeout: 260 seconds)
01:43:20  * fallsemojoined
01:48:53  * fallsemoquit (Ping timeout: 245 seconds)
02:01:20  <cpettitt>Is there any way to use the brfs transform with testling?
02:02:35  <defunctzombie>thlorenz: I would have expected it in browserify itself
02:03:17  <defunctzombie>thlorenz: md5 is cool because even if two modules are different by major number
02:03:18  <thlorenz>it is, but browser-resolve is part of finding the right package, so redirecting to a matching one that was cached makes sense
02:03:30  <defunctzombie>they may have internal files that didn't change
02:04:01  <defunctzombie>thlorenz: redirecting should happen higher up, browser resolve should still find the package
02:04:03  <thlorenz>defunctzombie: md5 may be too restrictive for files - it is the same as deduping packages 'exactly' by version number
02:04:15  <thlorenz>defunctzombie: I can try redirecting higher up
02:04:37  <thlorenz>but I'm sticking to deduping on package level, especially of all the false positiives
02:04:38  <defunctzombie>thlorenz: I wouldn't expect it to be the only thing.. I think your approach with close versions is also relevant
02:04:45  <thlorenz>ok
02:04:54  * fallsemojoined
02:05:03  <defunctzombie>but with md5 you don't need to do any of that to be 100% safe that what yo udedupe was a duplicate
02:05:03  <thlorenz>defunctzombie: Example: 'var f = require('./f')'
02:05:06  <defunctzombie>regardless of version
02:05:11  <thlorenz>could be in two files
02:05:29  <defunctzombie>heh
02:05:29  <thlorenz>but depending on where they are and what './f' resolves to it is totally differnt
02:05:45  <defunctzombie>yea.. would have to be something like module.exports = require('./lib');
02:06:04  <defunctzombie>anything else is likely to have other content that is not identical
02:06:12  <defunctzombie>but that is certainly an amusing case
02:06:37  <thlorenz>defunctzombie: I actually ran into this with my see-eat-sleep config files which were identical
02:07:14  <defunctzombie>one thing that makes this fail is that we no longer do path lookups client side
02:07:26  <thlorenz>I used https://github.com/thlorenz/dynamic-dedupe there and ended up making sure that 2 subdirs above the file are identical as well to avoid false positives
02:07:34  <defunctzombie>with those, you could actually treat the content the same
02:07:47  <thlorenz>yeah, but it would break detective
02:07:52  <defunctzombie>but the path lookup for require from that point different
02:08:02  <thlorenz>since I'd direct that to the wrong place ;)
02:08:19  <defunctzombie>it wouldn't break detective, it would just make the client require shim different, but yea
02:08:30  <defunctzombie>an amusing optimization after the fact haha
02:08:40  <thlorenz>ah, ok
02:08:57  <thlorenz>well for now I'll try to get the tests all to pass and finish dedupe on package level
02:09:01  <thlorenz>we really need this
02:09:12  <thlorenz>may have to finish this tomorrow morning though
02:09:56  <defunctzombie>I think this is awesome
02:10:12  <defunctzombie>and also think this needs to be a browserify thing and not browser-resolve
02:10:21  <defunctzombie>I don't think that makes it any harder
02:10:24  * jibayquit (Remote host closed the connection)
02:10:30  <defunctzombie>thlorenz: but will say, you need to not have the global cache
02:10:39  <defunctzombie>thlorenz: that is absolutely important
02:10:45  <defunctzombie>when packaging disjoint bundles
02:11:54  <thlorenz>defunctzombie: that's what reset is for
02:12:11  <defunctzombie>thlorenz: can't rely on reset as one module may still be building
02:12:29  <defunctzombie>you should just let the user pass in the cache or have separate instances of dedupe
02:12:45  <defunctzombie>we have hit this before with something in browserify... trying to remember what not
02:12:56  <defunctzombie>it is just safer if you don't have the global
02:12:57  <thlorenz>defunctzombie: what about each bundle chain gets its own instance of dedupe
02:13:07  <thlorenz>which closes over a cache
02:13:19  <defunctzombie>thlorenz: yes, in either case, this would be something that gets setup in browserify
02:13:23  <thlorenz>so every bundle chain has its own cache
02:13:24  <thlorenz>ok
02:13:27  <defunctzombie>yep
02:13:45  <thlorenz>thanks for that hint - hadn't thought of that
02:14:28  * fallsemoquit (Ping timeout: 246 seconds)
02:17:50  <thlorenz>defunctzombie: do you agree that --dedupe 'exact' should be a default and you'd have to explicitly turn it off via --dedupe 'none' ?
02:18:11  <defunctzombie>thlorenz: 100%
02:18:41  <defunctzombie>absolutely exact only by default, otherwise asking for strange cases
02:18:44  <defunctzombie>and debug issues
02:19:08  <defunctzombie>and yes, I think dedupe should happen by default
02:19:13  <thlorenz>coo
02:19:14  <thlorenz>l
02:20:04  <defunctzombie>thlorenz: a note on that md5 stuff
02:20:11  <thlorenz>defunctzombie: you still could have weird debug issues though - i.e. if you edit a node_module directly and your changes don't get picked up ;)
02:20:12  <thlorenz>yes?
02:20:39  <defunctzombie>hm, nvm.. was thinking you could do something fancy like md5 the deps too
02:20:43  <defunctzombie>but that doesn't work
02:21:31  <defunctzombie>thlorenz: I think we should make a note of that "edit a node module" thing.. I would also think about md5 of content on top of version check to double check
02:21:56  * defunctzombiethinks there is something interesting hidden within md5'ing content but can't think of it yet :)
02:22:14  <thlorenz>defunctzombie: but then you'd have to read all the modules even if you plan to dedupe them
02:22:27  <defunctzombie>thlorenz: it would go along the path of replacing require('./long/ass/path/to/foo.js'); with require(55);
02:22:36  <thlorenz>I'd suggest to just make a note and tell people to turn dedupe off when editing node_modules
02:22:42  <defunctzombie>which we hypothesized would be the next evolution for large stuff like d3
02:22:46  <defunctzombie>which has many many requires
02:22:50  * fallsemojoined
02:22:53  <defunctzombie>thlorenz: I agree about the note
02:23:13  <substack>cpettitt: use the browserify transform field in package.json
02:24:37  <thlorenz>defunctzombie: not sure how the d3 stuff relates?
02:24:38  * kumavis_joined
02:25:02  <substack>it would become something more like require_55()
02:25:39  <thlorenz>substack: in order to make the detective not find these?
02:25:53  <thlorenz>or to speed up resolution?
02:26:26  <substack>no, to optimize away the overhead of doing requires and to prune dead code
02:26:54  <defunctzombie>thlorenz: the issue came up when someone ported d3 to use requires
02:26:57  <thlorenz>ah, do you guys have a link where you discussed this? sounds interesting
02:27:09  <defunctzombie>the project ended up with lots of require('string we can't minify'); stuff
02:27:11  <defunctzombie>over and over
02:27:22  <defunctzombie>and we thought it would be cool to obfuscate that part away as well
02:27:27  <thlorenz>hm
02:27:36  <substack>thlorenz: part of what is weirding me out about dedupe is the minor/major thing
02:27:59  <substack>it seems like this is kind of thing should be handled by `npm dedupe`, not browserify
02:28:01  <thlorenz>substack: why it just allows you to configure how aggressive it dedupes
02:28:22  <thlorenz>substack: we need this dedupe since npm dedupe breaks once you link stuff
02:28:24  <substack>that's really weird and breaks the best thing about node modules
02:28:38  <substack>thlorenz: can't you just make a better version of `npm dedupe` instead?
02:28:44  <substack>or fix the existing `npm dedupe`
02:28:50  <substack>I really don't want this kind of thing in browserify core
02:28:56  <thlorenz>I don't think you can
02:29:16  <thlorenz>since that's how node works - it looks for modules in parent dirs
02:29:38  <substack>but you just did... you just wrote it inside of browserify instead of writing a tool that juggles module directories around
02:29:40  <thlorenz>once you link to something outside that lookup breaks and npm dedupe can do nothing about that
02:29:51  <cpettitt>substack: thanks! That seems to be the way to go. I'm getting an error with that though "Error: Referencepath is not defined (/Users/cpettitt/projects/dagre/test/dot-test.js)". I'm actually making a call to readdirSync - maybe that is not supported?
02:30:19  <thlorenz>substack: no I'm not deduping like npm dedupe at all since I do it during lookup instead of actually moving files
02:30:30  <thlorenz>so I have more power here
02:30:35  <substack>cpettitt: fs.readFileSync() is the only thing that works
02:30:58  <thlorenz>substack: also you don't want people's apps to break cause they forgot npm dedupe
02:31:02  <substack>thlorenz: but why is that better?
02:31:07  <substack>I would think that would be much worse actually
02:31:09  <thlorenz>i.e. suddenly they get two event busses
02:31:18  <cpettitt>substack: that would explain it. For now I hack shim that checks if I'm running in testling to get around it. Thanks for your help!
02:31:26  <substack>since it breaks the correspondence between how files are organized on disk and how browserify finds files to include
02:31:28  <cpettitt>have a shim even
02:31:43  <substack>cpettitt: don't do that
02:32:09  <defunctzombie>substack: dedupe is more important for client packaging than server.. I actually don't care to npm dedupe on the server ever
02:32:24  <defunctzombie>but when I package for client, I care a *little* bit more about it
02:32:36  * kumavis_quit (Quit: kumavis_)
02:32:51  <defunctzombie>substack: because space usage on server is not an issue, but on client we care
02:32:52  <thlorenz>also it can break apps that use singletons like a global event bus that they requuire
02:32:54  <substack>thlorenz: the real problem here is that how npm installs new modules into an existing dependency tree with existing modules is shitty and broken
02:33:04  <substack>we should be fixing that instead of cluttering browserify core with work-arounds
02:33:36  <defunctzombie>substack: that is a harder issue to fix :)
02:33:59  <thlorenz>substack: has nothing to do with npm, but even if I manually link modules together I'd expect to get the same 'event-bus' no matter if the file exists twice as a dependency in different modules
02:34:08  <cpettitt>substack: what would you suggest? I have some test code for my library that loads several graphs, applies some algorithms to them, and then checks invariants. Right now I scan a directory for those graphs. If I could give testing a manifest of files to bundle that might work.
02:34:26  <substack>thlorenz: "exists twice" could mean so many things
02:34:52  <thlorenz>substack: I meant a package exists twice
02:34:58  <substack>"exists"
02:35:10  <thlorenz>makes no sense to bundle that twice
02:35:17  <substack>it might!
02:35:24  <substack>it makes a ton of sense in certain circumstances
02:35:28  <thlorenz>well then you can set --dedupe 'none'
02:35:44  <substack>do the file hashes match? probably ok then
02:35:49  <thlorenz>or maybe we won't make deduping the default then
02:35:56  <substack>I wouldn't depend on the version listed in package.json at all though
02:36:00  <thlorenz>I'm deduping packages not files
02:36:09  <thlorenz>I'm looking up package versions
02:36:10  <substack>that's really wrong
02:36:15  <substack>don't do that ever
02:36:44  <substack>if there are local edits or you pull down a package from github instead of npm the files are going to differ
02:36:50  <thlorenz>why is that wrong? package names are unique and if they have the same version they should be identical
02:36:54  <substack>and be REALLY confusing to debug!
02:37:00  <substack>no!!!!~!
02:37:02  <thlorenz>then you turn off dedupe or don't use it
02:37:29  <substack>this is wildly divergent from how it works in node
02:37:44  <thlorenz>but very similar to npm dedupe
02:37:59  <substack>why can't we just say "make sure to `npm dedupe`" then?
02:38:05  <thlorenz>except that npm dedupe doesn't even allow you to specify how aggressively to dedupe
02:38:19  <thlorenz>because that breaks when you link packs during development
02:38:39  <thlorenz>and for client side development that breaks shit, like singletons
02:38:42  <substack>that sounds like the perfect fit for an external tool then!
02:38:46  <substack>a better `npm dedupe` command
02:38:55  <thlorenz>but how would that work?
02:38:57  <substack>isaacs will probably even bring it into npm core if it works well
02:39:09  <thlorenz>I mean it'd have to change how node looks up packages
02:39:15  <substack>just have it move files around
02:39:25  <thlorenz>so npm link then
02:39:53  <thlorenz>b/c then I'd have to link all deps of the pack I linked to back to where the pack would be in node_modules
02:40:43  <thlorenz>substack: I'm just trying to make things work smoothly - I mean I convinced people where I work to use browserify
02:41:04  <thlorenz>but if they cannot just link stuff without things breaking, that's not good
02:41:40  <substack>it doesn't break, the bundle is just bigger than it might otherwise be
02:41:45  <thlorenz>substack: it's very hard to develop a modularized app without being able to link
02:41:53  <thlorenz>no it breaks things like backbone
02:42:02  <thlorenz>cause that needs to be a singleton
02:42:16  <thlorenz>so I need to get the same one no matter how I require it
02:42:19  <substack>move linked dependencies up to the root node_modules?
02:42:29  <substack>ln -s ~/custom-backbone node_modules/backbone
02:42:46  <thlorenz>that could work, but now I have to teach everyone in my team that
02:42:57  <substack>write a bash script
02:43:02  <thlorenz>with browserify dedupe I wouldn't have to worry about that
02:43:05  <substack>there's even a `postinstall` field
02:43:07  <substack>correct
02:43:17  <thlorenz>I do npm dedupe as postingstall
02:43:26  <substack>but now everyone else has to worry about the unintended consequences of reasoning about very surprising deduping logic
02:43:44  <thlorenz>substack: so lets just say we don't make dedupe the default
02:43:53  <thlorenz>now you have to manually want to dedupe
02:44:14  <thlorenz>I don't see much of a problem there, it's just another cool browserify feature that makes your life easier
02:45:27  <thlorenz>substack: are you really totally hell bent on not allowing this? cause I can't think of a way to do this without adding some code to browserify
02:45:31  <substack>one thing I am entirely on board with having turned on by default is if the md5 hash of 2 files exactly match, only one of them should be bundled
02:45:40  <substack>but everything else should be opt-in
02:45:53  <substack>or even better, externalized
02:46:00  <defunctzombie>substack: can't do the md5 thing the naive way
02:46:11  <defunctzombie>substack: module.exports = require('./lib');
02:46:12  <substack>defunctzombie: why not?
02:46:14  <defunctzombie>would cause it to fail
02:46:27  <defunctzombie>if that was in index.js
02:46:32  <defunctzombie>and the only thing in the index.js
02:46:36  <defunctzombie>just as a trivial example
02:46:53  <substack>defunctzombie: you can just run the linked content in another context
02:47:04  <defunctzombie>right.. that is what would have to happen
02:47:08  <substack>that's fine
02:47:20  <thlorenz>substack: so that seems like another cool feature
02:47:21  <defunctzombie>which makes the client side require (module pack I think) more complex.. not sure
02:47:30  <defunctzombie>cause we don't have context currently
02:47:56  <thlorenz>substack: but are you ok with adding opt-in dedupe even if it adds code to browserify core?
02:48:16  <substack>thlorenz: I'm really skeptical about it still
02:48:44  <thlorenz>ok - well let me get the PR in - probably tomorrow - I'll try to keep code changes to a minimum
02:49:13  <thlorenz>substack: then you can tell me what you think - if not I'll have to use a fork at work since we really need this
02:49:30  <substack>thlorenz: the main thing I think is really surprising about it is that currently node and browserify have no notion of versions at all
02:49:31  <thlorenz>defunctzombie seems to aggree with me on how important dedupe is
02:49:34  <substack>only npm cares about versions
02:50:12  <thlorenz>you mean like require('foo:1.1.0') or something like that?
02:50:13  <defunctzombie>I 100% think we need to dedupe in some way regardless of npm
02:50:40  <substack>thlorenz: would just comparing the hash work for your use-case?
02:50:50  <defunctzombie>npm is not to be relied on.. npm installing without duplicates is only a suggestion in my mind
02:50:54  <substack>I can think of a really simple way to add hash checking
02:51:01  <defunctzombie>substack: it wouldn't work for his patch version stuff
02:51:30  <substack>defunctzombie: but that is in the scope of things that npm is concerned with
02:51:33  <defunctzombie>substack: since he wants to try to dedupe on patch version.. which I think needs more flushing out (like newest patch version would win out) or something else
02:51:40  <substack>and as long as we're patching things, we could be patching npm instead
02:51:52  <substack>or just writing a dedicated dedupe tool
02:51:53  <defunctzombie>substack: npm is concerned with ensuring that a module and its deps are installed on disk to be able to run
02:52:03  <defunctzombie>it is not concerened with taking up the least amount of disk space possible
02:52:23  <defunctzombie>and I personally don't see the value of dedupe for server as much as I do for client
02:52:24  <substack>I am so super skeptical of branching on what package.json's version says
02:52:34  <defunctzombie>substack: I agree
02:52:40  <defunctzombie>I am more in favor of md5 approaches
02:52:41  <substack>what if somebody has a linked dep in node_modules
02:52:45  <defunctzombie>as the first pass
02:52:53  <defunctzombie>and not patch version fuzzyness
02:52:58  <substack>but in node_modules/foo/node_modules there is another dep with the same name/version
02:53:17  <substack>name/version is NOT canonical in any sense
02:53:30  <substack>it doesn't tell you anything about what the package contents actually are
02:54:13  <defunctzombie>correct
02:54:24  <defunctzombie>especially given the gitname/repo stuff you can do
02:54:55  <thlorenz>so what is canonical then?
02:55:11  <defunctzombie>content
02:55:23  <thlorenz>well, content and surrounding
02:55:30  * fallsemoquit (Quit: Leaving.)
02:55:38  <defunctzombie>substack: also, npm does not dedupe git repo installs iirc which is another reason to dedupe in browserify ourselves
02:55:43  <defunctzombie>thlorenz: yea
02:55:47  <thlorenz>since depending on what relative paths resolve to the content could mean something different
02:55:47  <defunctzombie>thlorenz: content and context
02:56:00  <thlorenz>so how would you figure out the context?
02:56:17  <thlorenz>you'd have to get the content of the entire world around you
02:56:32  <thlorenz>everything that the module or its dependents require
02:57:38  <thlorenz>defunctzombie: as I said I did a poor men's version of context by saying that n parent dirs above the file have to match
02:57:49  <substack>that's weird
02:57:53  <thlorenz>but that is flawed and just good for development when you link
02:57:57  <thlorenz>substack: agreed
02:57:57  <substack>you can just load the content at runtime
02:58:17  <substack>that's the trick that webworkify uses
02:58:24  <thlorenz>but this needs to happen during the bundling process
02:58:25  <substack>arguments[4] and arguments[5] in any bundle
02:58:48  <thlorenz>so how can you rely on runtime?
02:58:56  <substack>all the bundling process needs to care about is that md5 hashes match
02:59:12  * timoxleyjoined
02:59:22  <thlorenz>ok, but then you may find false positives right?
02:59:23  <substack>when they match, install a shim module definition that points to the existing source with the current context
02:59:40  <defunctzombie>^ that is what should happen
02:59:53  <defunctzombie>and I think that is easy since you just wrap the js
02:59:58  <substack>yep!
03:00:35  <substack>plus, you get even smaller bundles if you have 2 versions of packages with mostly the same files
03:00:39  <thlorenz>defunctzombie: would that make dedupe obsolete - assuming we could get it to work?
03:01:47  <substack>and once you get straight-up md5 checking to work
03:01:58  <substack>you can get even crazier and start doing byte offset diffs
03:02:14  <thlorenz>substack: I'd suggest to possibly add dedupe even if that's true until we add that more granular md5 dedupe
03:02:18  <substack>for small differences in source files to apply patches at runtime
03:02:40  <thlorenz>otherwise I'll have to use my fork at work until then
03:02:45  <substack>thlorenz: this is pretty simple, I'll just see if I can get it working tonight
03:03:09  <substack>and if it doesn't address all of your use-case we can re-evaluate to figure out what's left
03:03:43  <thlorenz>substack: sounds good, I'll keep finishing up my dedupe approach -- mostly tests -- in the meantime
03:03:58  <thlorenz>then we can pick the best solution
03:05:22  <thlorenz>defunctzombie: what do you think - my approach won't be needed if substack implements what we just discussed right?
03:06:04  <substack>assuming it addresses all of your objections
03:06:16  <substack>if 2 files legitimately have different file contents then you still get 2 copies
03:06:24  <thlorenz>substack: that is fine
03:07:28  <thlorenz>substack: well actually that would only allow 'exact' dedupe, but should be fine during development
03:07:55  <thlorenz>in which case I could ensure to install exact same versions of the things that have to be identical
03:08:18  <thlorenz>and in combination with npm dedupe it would even work if versions don't match (and I don't link)
03:09:21  <thlorenz>substack: I believe your approach could have better results in general since it most likely will result in even smaller bundles than mine
03:12:23  * kriskowalquit (Quit: kriskowal)
03:12:56  <substack>one thing I'm thinking of
03:13:04  <substack>if there are 2 files, both with:
03:13:09  <substack>console.log('side effect')
03:13:13  <substack>module.exports = 555
03:13:15  * kriskowaljoined
03:13:30  <substack>if you require('./first.js') and require('./second.js') you only get 1 side effect
03:13:46  <substack>I can make this re-run the source, but then you get different references
03:14:10  <substack>for libs that require the same references like backbone and three.js that is problematic
03:14:46  <substack>or I can just point to the existing export ref, but that is surprising in how side-effects work
03:14:53  <substack>but that should be pretty rare at least
03:15:14  * dominictarrjoined
03:15:58  <substack>I think in this case probably it's sufficiently rare enough to have depended-upon side effects in files with exactly the same contents
03:16:37  <thlorenz>substack: I believe that you would want only one side effect
03:16:46  <thlorenz>cause that is how it is if you npm dedupe as well
03:17:12  <substack>ok yes, just making sure this is an acceptable trade-off first
03:17:17  <thlorenz>i.e. if you do something while being required you expect to get cached after and to have this run only once
03:17:24  <thlorenz>imo it is
03:18:30  <substack>ok wait I can't do this actually
03:18:36  <substack>I've got to re-evaluate the source
03:18:44  <substack>in the new context
03:19:37  <substack>because the depended-upon file could have its require() calls map to different files which might differ
03:20:04  <substack>the bundle will be tiny, but might not solve the instanceof problem with backbone and three.js
03:22:10  * missinglinkjoined
03:25:17  <thlorenz>substack: that's what I mentinoned earlier
03:25:30  <thlorenz>same source != same meaning
03:26:43  * timoxleyquit (Remote host closed the connection)
03:27:13  <substack>is it ok if this feature doesn't solve the duplicate instance problem?
03:27:16  <thlorenz>substack: not sure though why it wouldn't solve instanceof problem since I'd get only ONE backbone
03:27:30  <thlorenz>substack: that's the main reason I did dedupe
03:27:31  <substack>because this patch would re-evaluate the source in the new context
03:27:49  <thlorenz>I can't have two backbones - that breaks everything
03:27:53  <substack>ok
03:28:15  <thlorenz>we may consider using our approaches in tandem
03:28:23  <substack>yes I think that might work best
03:28:35  <thlorenz>i.e mine dedupes exact packages (if you turn it on) and yours removes duplicate files
03:28:43  <thlorenz>on a more granular level
03:28:59  <thlorenz>ok - gonna get some rest - will continue tomorrow
03:29:24  <substack>ok I'll just publish what I have for hashes when I get it working
03:29:28  <thlorenz>excited to see what you come up with, will finish my end in the morning
03:29:29  <substack>and hopefully your patch can build upon that?
03:29:33  <thlorenz>cool :)
03:29:55  <thlorenz>yep, should be possible - I mean dedupe should be pretty isolated from checking file content
03:29:55  <substack>it should give the dedupe code a good place to exist at
03:30:19  <thlorenz>I have the main impl at thlorenz/browser-dedupe
03:30:36  * timoxleyjoined
03:30:48  <thlorenz>working on getting this to handle all cases and adding more tests, but yours may be another module since it works with file content
03:31:27  <thlorenz>substack: ok, good luck talk to you tomorrow
03:34:30  * thlorenzquit (Remote host closed the connection)
03:36:10  * mikolalysenkoquit (Quit: Lost terminal)
03:43:10  * coderzachjoined
03:59:17  <substack>mbalho: https://github.com/rvagg/workshopper
03:59:24  <substack>rvagg already split this beast up into a separate module!
04:00:55  * shamaquit (Remote host closed the connection)
04:02:12  <defunctzombie>substack: I was away ..tldr on the final decision?
04:04:44  * mk30joined
04:07:55  * cpettittquit (Quit: cpettitt)
04:11:44  * mk30quit (Quit: Page closed)
04:14:12  * ircretaryquit (Ping timeout: 276 seconds)
04:24:41  <substack>defunctzombie: I already have the hash-checking code working
04:24:48  <defunctzombie>substack: +1
04:25:18  <substack>it just doesn't work with instance refs which was thlorenz's main use case
04:25:43  <substack>but we might be able to pull ideas from dedupe into the hash checking
04:36:57  <defunctzombie>instance refs?
04:37:24  * kumavis_joined
04:48:12  * jergasonjoined
04:48:20  * dominictarrquit (Quit: dominictarr)
05:06:20  * itprojoined
05:06:20  * itprochanged nick to ITpro
05:06:48  <substack>now it passes for the same instance refs
05:07:02  <substack>but I'm going to come up with a more complicated test because there's a case it doesn't cover
05:16:50  * jergasonquit (Remote host closed the connection)
05:18:54  <defunctzombie>substack: while you are poking around you should look at those .external changes :p
05:20:16  * coderzachquit (Quit: coderzach)
05:39:21  * missinglinkquit (Ping timeout: 276 seconds)
05:53:28  * st_lukejoined
06:25:27  * rxgxjoined
06:48:39  * rxgxquit (Quit: rage quit)
06:53:23  * calvinfoquit (Quit: Leaving.)
07:10:28  * st_lukequit (Remote host closed the connection)
07:11:05  * st_lukejoined
07:15:07  * st_lukequit (Ping timeout: 246 seconds)
07:22:03  * st_lukejoined
07:30:02  * kumavis_quit (Quit: kumavis_)
07:33:40  * ITproquit (Ping timeout: 246 seconds)
07:44:54  <substack>defunctzombie: published 2.29.0
07:45:06  <defunctzombie>substack: what new goodies does it have?
07:45:29  <substack>sophisticated, version-aware hash checking
07:45:44  <substack>or rather, (dependency hash)-aware
07:45:49  <defunctzombie>oooo
07:46:01  <substack>there's no version checking anywhere, just the dependency graph as usual
07:46:20  <substack>but if you ever have a duplicate file anywhere, you will get that file
07:46:30  <substack>only once
07:46:56  <substack>and if you have a duplicate file with exactly the same hashed dependency context, you will get the same instance
07:47:29  <substack>so if you have identical copies of backbone in node_modules/backbone and node_modules/foo/backbone with identical sub-dependencies, you will get the same instance for both
07:47:42  <defunctzombie>substack: nice, will run it on my codebase when I rebase my external stuff next week on 2.29
07:47:57  <defunctzombie>and see what wins I get
07:48:16  <defunctzombie>I expect quite a few since I use modules like domify and many components also use that module
07:49:49  <substack>https://github.com/substack/node-browserify/blob/master/test/hash_instance_context.js and https://github.com/substack/node-browserify/tree/master/test/hash_instance_context
07:50:04  <substack>and also the simpler test/hash.js and test/hash_instance.js
07:51:10  * mirkokieferjoined
07:59:33  * st_lukequit (Remote host closed the connection)
08:00:12  * st_lukejoined
08:04:54  * st_lukequit (Ping timeout: 264 seconds)
08:25:55  * mirkokieferquit (Quit: mirkokiefer)
08:28:12  * mirkokieferjoined
08:42:20  * calvinfojoined
08:47:58  * calvinfoquit (Quit: Leaving.)
09:06:41  * defunctzombiechanged nick to defunctzombie_zz
09:08:10  * dominictarrjoined
09:18:15  * nicholasfquit (Read error: Connection reset by peer)
09:18:46  * nicholasfjoined
09:45:32  * damonoehlmanquit (Quit: WeeChat 0.4.1)
09:47:47  * chilts_joined
09:48:08  * mirkokjoined
09:48:37  * chiltsquit (Ping timeout: 260 seconds)
09:48:37  * chapelquit (Ping timeout: 260 seconds)
09:48:38  * Guest74601quit (Ping timeout: 260 seconds)
09:50:08  * chapeljoined
09:56:53  <substack>dominictarr: ok I get into dublin sept 4th and leave sept 18th
09:57:56  <dominictarr>sweet!
10:02:33  * mirkokieferquit (Quit: mirkokiefer)
10:09:12  * mirkokieferjoined
10:12:45  <dominictarr>substack: just had a realization in the shower
10:12:55  <dominictarr>of the social impacts of a modular ecosystem
10:13:01  <dominictarr>vs a single large project
10:13:55  <dominictarr>related to what I was reading the other day about papua new guineaian tribes
10:14:06  <dominictarr>of the central highlands
10:14:44  <dominictarr>unlike most tribes in the pacific, there are no hereditary cheifs who are "leaders"
10:14:59  <dominictarr>all there are is "big men"
10:15:29  <dominictarr>people who by the force of the personality or accomplishments have gained more influence than other people
10:15:48  <dominictarr>but they still live in a hut like everybody else and eat what they grow.
10:16:41  <dominictarr>in communities like this there they decide everything in a bottom up way,
10:16:55  <dominictarr>just by talking about it
10:16:58  <dominictarr>but on one can give orders
10:17:28  <dominictarr>now, If you have a large project, with a BDFL (aka "chief")
10:17:46  <dominictarr>then the chief can make nearly all the decisions
10:18:04  <dominictarr>which is intimidating for potential contributors
10:18:17  <dominictarr>it creates much more asymmetry
10:18:23  <substack>and the onboarding takes a ton of effort
10:18:38  <substack>to make a patch good enough to appease the chief
10:18:45  <dominictarr>yes
10:18:52  <dominictarr>exactly
10:19:18  <dominictarr>and you can't do anything too radical without stepping on toes
10:20:24  <dominictarr>but if things are modular, then you are much more likely to get to a situation where a bunch of people have written something that a bunch of other people are using
10:21:10  <dominictarr>even used by the original author of the main module that attracted everything else
10:21:26  <dominictarr>this is more like "big men"
10:21:48  <dominictarr>you become a big man by doing something useful, but it's recprical
10:21:53  <substack>when code is more modular, there are more dependencies that get used
10:22:04  <dominictarr>yeah, created by more people
10:22:31  <substack>and bugs are more likely to shake out when lots of people are using libraries
10:22:44  <substack>even if indirectly through other modules
10:22:53  <dominictarr>sure, but that applies to popular large projects too
10:23:28  <dominictarr>but the main difference, is that there is a great deal more equality in the decision making process
10:24:05  <dominictarr>like, look at a levelup feature - everything is a concensus
10:25:55  <dominictarr>and also, everyone involved has created essential parts of the ecosystem that are used by everyone else
10:26:23  <dominictarr>so everyone has authority over a small part
10:37:46  <rvagg>speaking of which, substack you need to get your readstream cleaned up and we can get it released and you added to the project
10:40:58  * jcrugzzquit (Ping timeout: 245 seconds)
10:47:10  <substack>rvagg: what needs cleaned up?
10:47:27  <rvagg>there's inline comments in the PR
10:47:34  <substack>oh updating the tests?
10:47:40  <substack>ok on it
10:47:55  <substack>rvagg: I was playing your levelmeup thing too, very cool
10:48:19  <rvagg>cool, I hope you find some time to contribute.. I'm running out of time and have too much on my plate!
10:48:54  <rvagg>you too dominictarr, I needs me some help
10:49:27  <dominictarr>okay, sure, will take a look at it.
10:49:42  <rvagg>even if you just have thoughts on the progression of lessons
10:50:46  <substack>rvagg: I think the first one should be simpler
10:50:55  <substack>where you only get a single key
10:51:08  <substack>the first one is partly to make sure everybody's install is working ok anyways
10:51:20  <rvagg>mm, good point
11:01:52  <substack>rvagg: when I do Readable.call(this, extend(options, { objectMode: true }))
11:02:06  <substack>I get an error in the read-stream-test
11:02:38  <substack>aha
11:02:45  <substack>I think the encoding parameter interferes
11:02:52  <substack>so yeah, this is a bad idea to pass through
11:02:56  <rvagg>ah, ok
11:03:03  <rvagg>unless we just null out the encoding
11:03:09  <rvagg>but whatever, leave it out until it's asked for then
11:07:23  <substack>https://github.com/rvagg/node-levelup/pull/176#commits-pushed-f8a9aeb
11:07:39  <rvagg>substack: and you're happy to become a maintainer I assume?
11:07:59  <substack>yep
11:08:45  <rvagg>goodgood
11:40:27  * dominictarrquit (Ping timeout: 260 seconds)
11:44:57  * jolissjoined
11:47:44  * dominictarrjoined
11:48:56  <dominictarr>rvagg: workshopper needs to stdout into the user's pager
11:49:18  <rvagg>dominictarr: yeah... but ... windows
11:49:19  <dominictarr>so that you can see instructions at the top, even if you have a small screen
11:49:29  * ins0mniajoined
11:49:44  <dominictarr>okay, so on windows fallback to nothing
11:49:49  <rvagg>that's why I added `learnyounode print`
11:49:53  <rvagg>`learnyounode print | less`
11:50:05  <rvagg>prints the latest exercise, see note at the bottom of each exercise about that
11:50:09  <dominictarr>can use this https://github.com/substack/node-editor
11:50:35  <dominictarr>just make it default if stdout is a tty
11:50:42  <dominictarr>like git log does
11:51:35  <dominictarr>if you can point me to where instructions are output in workshopper I will send you a pull request
11:51:54  <rvagg>ok, do you want to add that? I'm slightly afraid of the cross-platform complexities, last thing we want it something going wrong when it needs to work and not being able to push an update to everyone using it; like at campjs where the network ground to a halt every time we were all doing stuff together so we handed around USB sticks
11:52:05  <substack>windows has `more`
11:52:25  <substack>var pager = process.env.PAGER || 'more'
11:52:28  <substack>should work fine
11:53:00  <rvagg>dominictarr: https://github.com/rvagg/workshopper/blob/master/workshopper.js#L308-L328
11:53:23  <rvagg>printText does the formatting work, I guess write it to a /tmp/ file first?
11:54:50  <dominictarr>rvagg: I think it needs one hello world example first, just so that you can get the format
11:55:06  <dominictarr>node program.js rvagg
11:55:12  <dominictarr>> "hello, rvagg!"
11:55:21  <dominictarr>so that you can get the format.
11:55:37  <rvagg>ok, there's this: https://github.com/rvagg/learnyounode/blob/master/problems/hello_world/problem.txt
11:55:46  <rvagg>and this: https://github.com/rvagg/learnyounode/blob/master/problems/baby_steps/problem.txt
11:55:51  <rvagg>could reuse one of those, or edit slightly
11:56:50  <dominictarr>right, maybe just provide the text in the example too, so they don't have to think about the boilerplate
11:57:13  <dominictarr>actually, providing boilerplate was hugely helpful in the distributed workshop.
11:57:35  * joliss_joined
11:58:38  * jolissquit (Ping timeout: 240 seconds)
11:58:38  * joliss_changed nick to joliss
12:00:49  <dominictarr>rvagg: what are appname and rootdir used for in the templates?
12:01:11  <rvagg>{appname} is configurable by the individual workshop app, so 'levelmeup' in this instance
12:01:25  <rvagg>{rootdir} is the install directory of the app, so you can ship it with docs and whatnot
12:01:35  <rvagg>like, I included the Node API docs in learnyounode
12:01:45  <rvagg>and I'm including levelup/leveldown docs in levelmeup
12:01:49  <rvagg>in case you have no internets
12:02:01  <rvagg>and also lets you copy dependencies from node_modules if you have no npm access
12:02:10  <rvagg>so.. the documents have those things substituted
12:03:35  <dominictarr>hmm, it's a pity about npm. npm install is part of the whole experience.
12:05:39  <rvagg>yeah, but if the network goes down.... who knows what it'll be like on the island (actually, you probably have a clue)
12:06:11  <rvagg>it died at campjs, we had ~20 more than last time when you were there and that many wireless devices just killed it, even if we had an outside connection the wifi couldn't keep up
12:07:14  <rvagg>but anyway, the instructions say to use npm but if you can't then there's a backup
12:07:50  <dominictarr>rvagg: cian is doing everything he can for this to be the conference where the internet doesn't suck
12:08:20  <dominictarr>but, based on my research
12:08:30  <dominictarr>the problem is the wifi it self
12:08:30  <rvagg>well... we'll see
12:08:42  <dominictarr>because radio is fundamentally multicast
12:08:46  <rvagg>yeah, too many devices just clogs up the ether
12:08:58  <dominictarr>but tcp is a unicast model
12:09:15  <dominictarr>yeah, because it's like having one wire
12:09:43  <dominictarr>(actually 2.4 ghz wifi only has 4 non-overlapping channels)
12:09:51  <dominictarr>so, 4 wires
12:09:52  <dominictarr>max
12:10:26  <dominictarr>it works great at home, but it doesn't scale.
12:11:06  <dominictarr>5 ghz is better… it has like 11 or 20 (i forget) non overlapping channels
12:11:28  <dominictarr>still, my philosophy is that I don't go to a conference to use the internet...
12:11:40  <rvagg>yeah, not much is on 5ghz atm tho
12:14:22  <dominictarr>yeah. wifi was just simply not designed for tech conferences.
12:15:11  <dominictarr>If I was organising a conference, there would be no wifi.
12:16:30  <rvagg>next campjs is probably going to have wires on all the tables
12:21:29  <dominictarr>hang on… how do pagers even work?
12:21:46  <dominictarr>if you pipe to the standard input… how is it reading the movement keys?
12:22:12  <rvagg>you have to write to a tmp file first I believe
12:22:25  <rvagg>but I'll let you work that out cause I'm off
12:24:37  <dominictarr>okay, I got it working
12:42:53  <dominictarr>substack: have you read about plan9?
13:01:26  * tilgoviquit (Ping timeout: 264 seconds)
13:01:31  * mirkokieferquit (Quit: mirkokiefer)
13:17:17  * thlorenzjoined
13:21:34  * thlorenzquit (Ping timeout: 246 seconds)
13:26:53  * nicholas_joined
13:29:09  * jez0990_joined
13:29:24  * jan____quit (Read error: Operation timed out)
13:29:25  * robertkowalskiquit (Read error: Operation timed out)
13:29:27  * nicholasfquit (Ping timeout: 240 seconds)
13:29:27  * jjjohnny_quit (Ping timeout: 240 seconds)
13:29:28  * jez0990quit (Read error: Operation timed out)
13:29:28  * Domenic_quit (Ping timeout: 240 seconds)
13:29:29  * paul_irishquit (Quit: ZNC - http://znc.sourceforge.net)
13:29:29  * brianloveswordsquit (Ping timeout: 240 seconds)
13:29:30  * philipnquit (Read error: Operation timed out)
13:29:30  * FireFlyquit (Read error: Operation timed out)
13:29:34  * brianloveswords_joined
13:29:41  * FireFlyjoined
13:29:44  * jjjohnnyjoined
13:29:48  * philipnjoined
13:30:25  * jesusabdullahquit (Read error: Connection reset by peer)
13:30:32  * jesusabdullahjoined
13:31:52  * paul_irishjoined
13:34:22  * robertkowalskijoined
13:42:43  * jan____joined
13:43:10  * timoxleyquit (Read error: Connection reset by peer)
13:43:48  * timoxleyjoined
13:56:40  * jolissquit (Ping timeout: 256 seconds)
13:58:16  * thlorenzjoined
14:01:53  * jolissjoined
14:03:40  * mirkokieferjoined
14:05:24  * AvianFlujoined
14:10:43  <thlorenz>substack: ping
14:21:28  * coderzachjoined
14:37:35  * coderzachquit (Quit: coderzach)
14:39:02  * coderzachjoined
14:48:31  * jan____quit (Changing host)
14:48:31  * jan____joined
15:09:44  * mcollinajoined
15:20:59  * coderzachquit (Quit: coderzach)
15:26:31  <dominictarr>mcollina: hey
15:29:53  * coderzachjoined
15:32:18  * mikolalysenkojoined
15:37:13  * yorickjoined
15:37:53  * Domenic_joined
15:40:25  <dominictarr>ralphtheninja: you linked the perfect talk that I needed to hear right now for a current mad science idea
15:44:39  * jolissquit (Quit: joliss)
16:03:15  <ralphtheninja>dominictarr: the network thingie?
16:03:28  <dominictarr>yeah, half way through it now
16:03:45  <ralphtheninja>cool, it was refreshing to listen to her, she explains really well
16:04:07  <ralphtheninja>I don't understand even half of it, but something stuck at least
16:04:59  * mikolaly1enkojoined
16:08:14  * mikolalysenkoquit (Ping timeout: 240 seconds)
16:11:35  <dominictarr>ralphtheninja: it's pretty horrifying actually
16:11:52  <dominictarr>"nobody listened to me so everybody did it wrong"
16:12:04  <dominictarr>no wonder we are in the mess we are in
16:12:49  <jaz303>what's the url of this talk?
16:24:01  * mcollina_joined
16:26:56  * mcollinaquit (Ping timeout: 240 seconds)
16:27:17  * timoxleyquit (Remote host closed the connection)
16:27:58  * mikolaly1enkoquit (Quit: Lost terminal)
16:31:59  <dominictarr>http://www.youtube.com/watch?v=LbZ5ruco0jM&feature=youtu.be
16:32:18  <jaz303>thanks!
16:40:37  * mcollina_quit (Read error: Connection reset by peer)
16:41:13  * mcollinajoined
16:49:08  <dominictarr>^highly recommended
16:49:40  <jaz303>watching it now
16:50:11  * jcrugzzjoined
17:08:06  * shamajoined
17:11:05  * thlorenzquit (Remote host closed the connection)
17:16:40  <dominictarr>ralphtheninja: jaz303 mcollina so the crazy new idea is a routing layer for everything
17:17:02  <dominictarr>like, ideally, everything could just have an ipv6 (or whatevs) address
17:17:52  <dominictarr>every object, every file, every gif, every tab, every iframe, every bacteria (there are enough ipv6 addresses for that)
17:17:57  <dominictarr>but that is never gonna happen.
17:18:12  <dominictarr>instead, what we will get is an epic polyfil
17:19:00  <dominictarr>basically, everything will become a router for it's inner parts
17:19:32  <dominictarr>so like, a webserver has an ip address, but also browser tabs that are connected only to it
17:19:45  <dominictarr>so, it will just route for those tabs
17:20:04  <dominictarr>each tab can assign itself an address (or multilpe addresses)
17:20:25  <dominictarr>so each iframe inside of it has an address too
17:22:02  <dominictarr>so, an iframe opens a stream… and it connects to an address.. but if that address is another iframe in another tab on the same computer then the top tab can just route it there easily!
17:22:31  <dominictarr>but, it will be possible to pipe from a command line tool to a tab in your browser
17:22:41  <dominictarr>by using some sort of relative path
17:29:13  <jaz303>sounds interesting
17:29:29  <jaz303>plan9 taken to the extreme
17:29:43  <jaz303>GUI object hieararchies being exposed over the filesystem
17:31:39  <jaz303>that in itself would be crazy, imagine you could create an interface by creating a directory structure
17:32:05  <jaz303>and the the event handler code for each button as a JS file, or whatever, in the folder
17:32:20  <jaz303>then wire up compnonents using symlinks
17:32:33  * coderzachquit (Quit: coderzach)
17:32:52  <jaz303>to open another instance of it, you just cp it somewhere
17:38:37  * cpettittjoined
17:40:35  <dominictarr>jaz303: yeah. I've had to look into plan9 because of this
17:40:42  <dominictarr>definately similar ideas
17:41:05  <dominictarr>but instead of everything is a fs, everything is a server
17:41:26  <dominictarr>so, networking is the fundamental construct, not fs.
17:41:28  <jaz303>so it's a flat space?
17:41:40  <jaz303>and the relationships need to be discovered?
17:41:53  <dominictarr>no. each thing is a router for it's subparts
17:42:06  <dominictarr>so a tab can create iframes, elements etc
17:42:13  <jaz303>sorry i meant, flat address space
17:42:16  <dominictarr>and it's responsible for routing to those
17:42:30  <dominictarr>well, heirachical i guess
17:42:32  <chapel>I have a question for anyone that cares about code api design, what would you call a method to add a function to a scoped flow control library, atm I am using add, but I don't think that is clear enough
17:43:27  <dominictarr>chapel: "then" "andThen" "next" ?
17:43:40  <chapel>well, they are named
17:43:51  <chapel>I am deciding if I want to allow then like functionality
17:44:21  <chapel>Im essentially making a lib that makes doing traditional named function callbacks easier
17:44:32  <jaz303>dominictarr: so if i wanted to, say, pipe a blog post i'm writing into a textarea hosted in an iframe, what would be the discovery process?
17:44:46  <dominictarr>right.
17:44:54  <chapel>I am torn with supporting promise like terminology without actually being a promise
17:45:20  <dominictarr>when you create something, you give it an address
17:45:31  <dominictarr>or it tells you what address it wants to have
17:46:06  <dominictarr>so, you'd have to ask the tab what things it has
17:46:33  <dominictarr>or, given permissions you could just pipe to the window manager - and say! do something sensible with this!
17:46:41  <dominictarr>or new window!
17:46:46  <dominictarr>or "new tab!
17:47:02  <dominictarr>or split pane X horizontally and put it there
17:47:20  <dominictarr>create instance of X application in Y pane and send this to it
17:47:26  <chapel>this is the api example I have now https://gist.github.com/chapel/311c246c52708ecf8324
17:50:03  <jaz303>man i need to show you what i've been making
17:50:20  <jaz303>it's not network centric but there might be some ideas for plundering
17:50:46  <jaz303>i love the idea
17:52:55  <jaz303>have you started making any of this?
17:54:15  <dominictarr>jaz303: just toying around a little bit, and figuring out how bits will go together, like postMessage between windows/tabs/frames/workers
17:54:46  * coderzachjoined
17:54:55  <jaz303>are you going to start with a browser version?
17:54:56  <dominictarr>looking at this another way, I have been working on this for about 18 months, but just didn't realize ;)
17:55:33  <dominictarr>jaz303: yeah, the largest part of my motivation is about making this work as a UI thing.
17:55:34  <chapel>updated gist with how I would write that callback flow normally https://gist.github.com/chapel/311c246c52708ecf8324
17:55:56  <dominictarr>I want visual UI stuff to be as composable as unix pipes
17:56:11  <chapel>dominictarr: that would be nice
17:59:16  <dominictarr>like, there are so many things that are a time series graph
17:59:34  <dominictarr>yet, just getting them into something you can see visually is pretty hard
18:00:01  <jaz303>yep
18:01:04  * mikolalysenkojoined
18:01:57  <jaz303>im gonna go and get this thing in a demoable state
18:02:08  <dominictarr>sweet!
18:02:28  <jaz303>back in a couple of days
18:40:30  * mcollinaquit (Read error: Connection reset by peer)
18:47:36  * thlorenzjoined
19:08:01  * AvianFluquit (Remote host closed the connection)
19:10:04  * cpettittquit (Quit: cpettitt)
19:16:48  * thlorenzquit (Remote host closed the connection)
19:18:50  * cpettittjoined
19:22:58  * jolissjoined
19:26:10  * thlorenzjoined
19:47:59  <substack>thlorenz: pong
19:48:09  <thlorenz>hey - nice work!
19:48:19  <thlorenz>just had two questions
19:48:50  <thlorenz>1. should we still add option to dedupe since that allows users to be as aggressive as they want to be about slimming the bundle?
19:49:23  <thlorenz>2. I saw that you redirect the duplicate via a require call to the one that it is a duplicate of
19:49:56  <substack>yes because require() has the machinery to generate an export ref if it doesn't exist yet
19:49:58  <thlorenz>substack: I was wondering why we don't just redirect whoever is requiring the dupe to the other one and not include the dupe all together?
19:50:18  <substack>because that is really tricky
19:50:28  <thlorenz>substack: ok, I was doing it that way in my dedupe, but I guess I was at package level so it was easier
19:50:34  <substack>and it doesn't work for the other case where the hashes match but not the dependency list context
19:50:48  <thlorenz>ok not a big deal anyways - this is awesome as it is!
19:51:17  <thlorenz>so how about dedupe do you think we still should include that?
19:51:44  <substack>does the patch that just landed address your use-case completely?
19:52:03  <substack>or do you need more aggressive deduping
19:52:14  <thlorenz>substack: if it fixes instanceof it will make sure I have only one bb as long as they are exactly the same version
19:52:24  <substack>it does
19:52:30  <substack>I tested with backbone explicitly
19:52:36  <thlorenz>however I may want to maker sure to only get one even if the versions are slightly different
19:52:54  <thlorenz>I could use npm dedupe first, but then we still have the problem when I linkg
19:52:58  <dominictarr>substack: can terminate resize yet?
19:53:09  <substack>thlorenz: if you link, won't all the links be the same?
19:53:17  <substack>dominictarr: nope :/
19:53:21  <thlorenz>substack: only if I use the exact same versions
19:53:47  <substack>dominictarr: I'm not sure what the mechanism is to set the screen size when I get a SIGWINCH
19:54:08  <substack>or rather, when I get an onresize in the browser and need to send a SIGWINCH
19:54:19  <thlorenz>substack: I think it'd be nice if I can weed out non-exact duplicates as well by supplying a match criteria (i.e. minor needs to be same to be considered equal)
19:54:23  <dominictarr>substack: hmm. need that. I want x-monad for the browser
19:55:03  * jolissquit (Quit: joliss)
19:55:19  <thlorenz>substack: lets see what defunctzombie_zz thinks, my immediate case is solved (as long as I make sure to have exact same versions), but I still think having an opt-in dedupe would be nice
19:55:45  <substack>thlorenz: what about a tool that just detects the presence of off-versions?
19:56:04  * jolissjoined
19:56:22  <thlorenz>substack: doing this dynamically is much more powerful since you don't have to mover around any physical files
19:56:38  <substack>but wouldn't you want to move around the files?
19:56:43  <thlorenz>also you have way more information when inside the chain in order to make the correct decision
19:56:44  * jolissquit (Client Quit)
19:56:52  <substack>if they don't match, no use keeping them around making things more complicated
19:57:20  <thlorenz>substack: no since if I link it'd be very confusing to overwrite things with stuff from somewhere else
19:57:48  <substack>thlorenz: the biggest problem I see is that name/version in package.json is completely unreliable
19:57:58  <thlorenz>also you'd have to remember to run the tool every time after you link - I'd rather have it happen automatically when I opt in
19:58:05  <substack>especially if you have local edits or symlinks to working builds
19:58:08  <thlorenz>what about the hash
19:58:09  <thlorenz>?
19:58:15  <substack>the hash of what?
19:58:22  <thlorenz>in packag.json
19:58:35  <substack>that's not consistently present either
19:58:35  <jesusabdullah>substack: it's from the mountains.
19:58:41  <jesusabdullah><3
19:59:01  <substack>thlorenz: if you have a symlink to a checked out repo dir, there's no hash in package.json
19:59:09  <jesusabdullah>substack: what're you up to these days anyway? Haven't caught up with your life in a while :)
19:59:26  <jesusabdullah>substack: last winter/spring I've been in nodejs seclusion
19:59:41  <thlorenz>substack: IMO if you opt in to dedupe and then edit your packages in node_modules that's your own fault ;)
19:59:57  <thlorenz>I discussed with defunctzombie_zz earlier that we could put a note not to do that
20:00:11  <substack>jesusabdullah: just going to europe in 11 days, then back to SF for a week, then back to europe, then columbia
20:00:17  <substack>and possibly some more places after those
20:00:18  <jesusabdullah>aha
20:00:21  <jesusabdullah>exciting
20:00:29  <jesusabdullah>I still never get to go to conferences :'C
20:00:40  <jesusabdullah>but I still have my fingers crossed for speaking at cascadiajs
20:00:43  <jesusabdullah>we'll seeeeeeeeeee
20:01:05  <thlorenz>substack: I'm just afraid of the case where everything works and some dependent updates backbone and the others don't and suddenly the app breaks
20:01:26  <substack>thlorenz: I think a script to detect that case would be best
20:01:32  <thlorenz>or it works via npm dedupe, but once I link during development it breaks
20:01:40  <substack>also `npm shrinkwrap`
20:02:22  <thlorenz>substack: ok I see what you mean - I guess I could try - it's much more complex and less reliable than doing it inside the bundle chain though
20:02:31  <substack>thlorenz: if you create links with exactly the same file contents everything should be 100% fine
20:02:53  <substack>if you have different contents, that can't possibly ever work in a clean way that's not a hacky heuristic
20:03:13  <thlorenz>substack: I thought about that, i.e. if I link a package I'd keep it's dependents in the original tree and link back to that from it
20:03:36  <thlorenz>substack: npm dedupe works this way though (it's not exact)
20:04:09  <thlorenz>it only makes sure that majors are the same - the dedupe that I have lets you specify that
20:05:27  <substack>but major/minor isn't trustworthy, ESPECIALLY if you're linking to custom versions!
20:05:41  <jesusabdullah>fuck it, I say
20:05:44  <thlorenz>substack: I agree, but I would let the user decide that
20:05:45  <jesusabdullah>do it live, that's my advice
20:06:01  <thlorenz>i.e. you can say that patches are ok
20:06:20  <thlorenz>I mean we all do when we declare dependents ;) except maybe defunctzombie_zz
20:07:25  <thlorenz>substack: anyways lets shelf this for now and see what others think about this - I'll think about some alternatives in the meantime
20:07:32  <substack>thlorenz: but then which version if the "correct" one?
20:07:36  <substack>*is
20:07:39  <thlorenz>the latest one
20:07:50  <thlorenz>same way when you install ~0.0.1
20:07:57  <thlorenz>0.0.3 is the correct one
20:08:00  <thlorenz>if it is the altest
20:08:04  <thlorenz>latest
20:12:04  <substack>one thing you can do is just var seen = {}; bundle.on('package', function (pkg) { if (seen[pkg.name] !== pkg.version) console.log('DUPLICATE ' + pkg.name + '@' + pkg.version); seen[pkg.name] = pkg.version })
20:12:16  <substack>with a detector tool
20:12:22  * itprojoined
20:12:22  * itprochanged nick to ITpro
20:12:35  * thlorenzquit (Remote host closed the connection)
20:15:49  * dguttmanjoined
20:24:01  <dominictarr>jesusabdullah: speaking is overrated. buying a ticket is great, because then you can relax!
20:25:41  * ITproquit (Ping timeout: 248 seconds)
20:26:08  <jesusabdullah>dominictarr: yeah definitely, going to do that for something when I finally become a multithousandaire
20:26:36  <dominictarr>jesusabdullah: good plan!
20:26:45  <jesusabdullah>inorite :3
20:26:56  <jesusabdullah>but I really do want to give this talk, the one I proposed for cascadiajs
20:27:01  <dominictarr>jesusabdullah: how is utah?
20:27:03  <jesusabdullah>I think it could be really good! For me, anyway
20:27:12  <jesusabdullah>dominictarr: not bad! It's nice here
20:28:46  <substack>I've only attended a tech conf once >_<
20:30:06  * thlorenzjoined
20:30:23  <thlorenz>substack: sorry got disconnected got only until 'with a detector tool'
20:30:52  <thlorenz>so that would allow me to print a warning, but not fix things - still better than nothing I guess
20:31:24  * mikolalysenkoquit (Ping timeout: 240 seconds)
20:31:41  * cpettittquit (Quit: cpettitt)
20:31:44  <thlorenz>substack: or is there a way to provide a hook which allows me to manipulate the modules before they go into browser-pack?
20:33:00  <substack>thlorenz: I think just detecting the issues would be a good place to start
20:33:19  <substack>and then you can factor-out common packages up to the highest common level
20:33:43  <substack>like `npm dedupe`
20:33:51  <substack>or perhaps just fix `npm dedupe`
20:34:20  <thlorenz>:) not sure if that is possible since once you link you break node lookup mechanism
20:34:32  <thlorenz>probably provide a better npm link instead
20:39:38  * mikolalysenkojoined
20:41:32  * coderzachquit (Quit: coderzach)
21:08:48  <dominictarr>substack: hmm, so the problem with resizing is at the shux end, right? when you resize the browser, you need to tell the other end you are a different size now
21:12:56  <substack>yes
21:13:12  <substack>you tell bash by sending it a SIGWINCH
21:13:20  <substack>but I don't know how to tell it what the size is
21:17:39  <dominictarr>hmm, a signal doesn't seem to have any arguments
21:18:22  * nicholas_quit (Read error: Connection reset by peer)
21:18:33  * thlorenzquit (Remote host closed the connection)
21:18:47  * nicholasfjoined
21:24:11  * kenperkinsjoined
21:26:43  * coderzachjoined
21:29:51  <dominictarr>if i was designing terminal protocols, I would have made the terminal size be controled with an escape code
21:32:41  <dominictarr>hmm, maybe if we just used https://npmjs.org/package/pty.js
21:36:08  <dominictarr>aha! https://github.com/chjj/pty.js/blob/master/src/unix/pty.cc#L290-L299
21:36:11  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:36:12  <dominictarr>ioctl
21:36:27  <dominictarr>(that is some important unix thing...)
21:37:27  <dominictarr>right. ioctl is for weird extensions that some io devices have
21:37:50  <dominictarr>like, telling a cdrom to eject a disk, or telling a terminal to resize
21:40:36  <dominictarr>here we go http://en.wikipedia.org/wiki/Ioctl#Terminals
21:43:31  <dominictarr>isaacs: is there a reason that node.js doesn't have a way to do ioctl?
21:47:16  * nicholasfquit (Remote host closed the connection)
21:48:28  * jcrugzzquit (Ping timeout: 245 seconds)
21:48:34  * AvianFlujoined
21:49:34  * AvianFluquit (Remote host closed the connection)
21:54:23  * st_lukejoined
21:56:12  * coderzachquit (Quit: coderzach)
22:01:24  * Domenic_changed nick to Domenic
22:01:33  * Domenicchanged nick to Domenic_
22:02:49  * yorickquit (Remote host closed the connection)
22:07:15  <dominictarr>Raynos: hey
22:13:40  <substack>I've almost cracked the puzzle of doing live updating, server+browser rendering in a sensible way
22:13:56  <substack>soooo close
22:15:01  * jcrugzzjoined
22:20:31  <dominictarr>front end frame works should be more like window managers: https://github.com/dominictarr/vec2-layout
22:23:45  * jcrugzzquit (Ping timeout: 245 seconds)
22:32:51  * mikolalysenkoquit (Ping timeout: 260 seconds)
22:39:12  * mikolalysenkojoined
22:50:08  * st_lukequit (Remote host closed the connection)
22:50:50  * st_lukejoined
22:53:22  * st_lukequit (Remote host closed the connection)
22:57:18  * dominictarrquit (Quit: dominictarr)
23:09:36  * thlorenzjoined
23:15:53  * timoxleyjoined
23:19:11  <daleharvey>what do you guys use for node + browser testing?
23:22:02  <substack>daleharvey: http://npmjs.org/package/tape
23:23:08  <daleharvey>cheers
23:23:25  <substack>then to run it in a browser locally, `npm install -g testling; testling test/*.js`
23:23:34  <substack>prints all its test output to stdout
23:23:46  <substack>sets $? to 0 on success, non-zero on failure
23:24:16  <substack>and you can just run each test file by doing `node test/foo.js`
23:24:32  <substack>or you can `npm install -g tape` and then do `tape test/*.js`
23:24:34  * thlorenzquit (Remote host closed the connection)
23:25:15  <substack>or you can just browserify your tests yourself and run them however you want browser-side
23:30:26  <daleharvey>hmm weird, deepQual doesnt seem to be working right
23:30:34  <daleharvey>*deepEqual
23:31:10  <daleharvey>http://pastie.org/8269524
23:31:43  <daleharvey>oh, just needed a plan
23:34:36  <daleharvey>https://ci.testling.com/guide/quick_start looks borked
23:37:16  * mirkokieferquit (Quit: mirkokiefer)
23:47:40  * missinglinkjoined
23:49:21  * coderzachjoined
23:55:56  * timoxleyquit (Remote host closed the connection)