--- Log opened Mon May 13 00:00:44 2013
00:04 < ralphtheninja> mbalho: anathem noted, reading cryptonomicon right now
00:05 < ralphtheninja> seems stephenson is a common favorite in here :)
00:07 < rvagg> ralphtheninja: I *know* you'd like Withur We, grab that too, totally up your alley I reckon
00:09 < ralphtheninja> rvagg: cool! this one http://www.amazon.com/With%C3%BBr-We-ebook/dp/B003R0LPEA/ref=sr_1_1?ie=UTF8&qid=1368403741&sr=8-1&keywords=withur+we ?
00:10 < ralphtheninja> gonna be in total mad science mode after this summer :D
00:10 < rvagg> ralphtheninja: yes, or free pdf if you can handle reading it as a pdf: http://www.withurwe.com/
00:12 < ralphtheninja> rvagg: this is definitely up my alley hehe
00:13 < rvagg> aye
00:16 < ralphtheninja> I should cut down on stupid series and read more instead
02:55 < substack> defunctzombie_zz: is there a way we can make that .coffee thing work in a non-global way?
02:55 < substack> I really want to avoid the "to use this module you must enable the .coffee extension" problem if we have this feature at all
03:16 < mikolaly1enko> jjjohnny:  just saw your message now
03:16 < mikolaly1enko> basically, the imaginary part is necessary to encode the "phase"
03:16 < mikolaly1enko> though it is combined with the real part of a signal
03:17 < mikolaly1enko> recall euler's formula:
03:17 < mikolaly1enko> r * e^{i theta} = r cos(theta) + i * r * sin(theta)
03:17 < mikolaly1enko> the real + imaginary part is enought to encode amplitude (r) with phase (theta)
03:18 < mikolaly1enko> for real valued functions, you get frequencies in complex conjugate pairs
03:18 < mikolaly1enko> so the entire function is real valued
03:19 < mikolaly1enko> though thinking about what I am saying, I am probably not explaining this well.  There is a lot of background material here that you need to understand for this to make sense
03:19 < mikolaly1enko> as a first question, do you know about eigenvalue problems?
03:26 < substack> thinking some very subversive thoughts now
03:28 < substack> so much technical instruction focuses on the minutiae and so little on the aesthetics and the philosophy
03:29 < substack> a programming book that does not also heavily discuss rationality and metacognition will leave its readers very susceptible to confused ideas like GoF or java
04:12 < mikolaly1enko> jjjohnny:  if you know about eigenvectors, a "simpler" way to see why complex values are necessary is to look at solutions to polynomials
04:13 < mikolaly1enko> if you have a polynomial (even with just real coefficients) then finding its roots requires brining in complex numbers
04:13 < mikolaly1enko> and finding eigenvalues amounts to solving a polynomial equation
04:13 < mikolaly1enko> namely, the characteristic equation:  det(A I - lambda I) = 0
04:14 < mikolaly1enko> the fourier transform is the solution to a kind of eigenvalue problem
04:14 < mikolaly1enko> so it requires bringing in complex numbers in order to solve it
04:14 < mikolaly1enko> for the same reason that you need complex numbers to solve polynomial equations
04:15 < mikolaly1enko> in fact, the basic thing the fourier transform does is that it solves the eigenvalue problem for shift operators
04:15 < mikolaly1enko> where a shift is just something that translates a function left/right some amount
04:20 < mikolaly1enko> substack: re philosophy of technical instruction, I'm not sure how much place it has in education.  I think students should discover it on their own, rather than having it handed to them on a platter
04:20 < mikolaly1enko> it would be good to cultivate a sort of mystery of philosphy, teach techniques but also teach students to question and search for better answers
04:24 < substack> I think there is already a good template for this kind of discourse: parables
04:25 < substack> the lessons are general and it's more about training your mind to notice when they apply to your specific problem
04:40 < jcrugzz> substack: yes correlations through parable type stories can be quite powerful
04:40 < jcrugzz> i like
04:41 < substack> a parable followed by a concrete exercise that demonstrates the primary lesson
04:42 < substack> but full of subversive ancillary lessons like only trusting authority insofar as their arguments are sound and justified
04:42 < substack> I've already fleshed out a basic one involving top-down vs bottom-up designs
04:44 < substack> whereupon the arrogant queen with many resources embarks upon a top-down design for her recently-destroyed castle and the nimble dutchess builds a castle out of simple, reusable components and is much more responsive to changing circumstances
04:45 < substack> and then for the practical exercise the reader builds a castle out of code using each approach: top-down and bottom-up
05:49 < juliangruber> http://demo.peerkit.com/static/index_demo.html
05:52 < juliangruber> for distributing load on websites across their visitors
05:53 < juliangruber> still requires a server to do the webrtc things and give hashsums etc
10:30 < substack> https://github.com/substack/node-shell-quote#parsing-shell-operators
10:34 < djcoin> hey substack, did you have a look at : https://github.com/substack/emit-stream/pull/3 ?
10:36 < substack> looking
10:36 < substack> oh right
10:36 < substack> djcoin: your editor is really spammy
10:36 < substack> configure it not to thrash whitespace
10:36 < substack> I kind of just ignore those pull requests that thrash whitespace
10:37 < djcoin> Really ?
10:37 < substack> yes
10:37 < substack> it's really annoying
10:37 < substack> don't do that
10:37 < substack> only update lines that actually matter
10:37 < djcoin> Well, to me you should fix yours :)
10:37 < djcoin> yeah that's why I put it in a separate commit
10:37 < substack> mine is not broken
10:37 < substack> it's my code
10:37 < substack> I don't like cherry-picking commits
10:38 < substack> note how all the whitespace is self-consistent
10:38 < djcoin> Well, as you wish your excellence :) i will skip this commit then
10:38 < substack> don't mess with self-consistent whitespace ever
10:40 < substack> the biggest problem is that when your editor thrashes all the whitespace it obscures what the changes actually are
10:41 < djcoin> Exactly, that s why you should get rid of trailing whitespaces from the start
10:41 < djcoin> and that's why i made a separate commit
10:41 < substack> they are not trailing
10:41 < substack> they are leading
10:41 < substack> I like code this way
10:41 < djcoin> this is called trailing
10:42 < substack> it's not consistent that empty lines are not also indented
10:42 < substack> my internal model of how whitespace works applies equally to empty lines
10:43 < djcoin> https://www.google.fr/search?q=trailing+whitespaces => http://www.gnu.org/software/emacs/manual/html_node/emacs/Useless-Whitespace.html, for example :)
10:43 < substack> I give zero shits about what other people think.
10:43 < djcoin> But I will stop on this flamewar, I know I won't change your mind and that's not my point
10:43 < djcoin> yeah I know
10:43 < substack> I'm going to ignore any pull request that includes significant formatting changes.
10:44 < djcoin> Yeah, i perfectly understood
10:44 < substack> that is not something that pull requests should do
10:44 < substack> ever
10:44 < djcoin> what about the bug then ?
10:44 < substack> I don't even know what the bug is.
10:44 < substack> but you wrote tests for it so I don't really care
10:44 < djcoin> Thats the point of the issue I opened and of this PR
10:48 < djcoin> substack: any other comments on this PR to avoid useless round-trip ?
10:49 < substack> I usually just make a new test file
10:49 < substack> you seem to have grown the existing one quite a lot
10:50 < djcoin> Well there was one test - I added another one :)
10:50 < substack> I would usually do: cp emit.js newthing.js
10:50 < substack> I don't like test files that get particularly big
10:50 < substack> they get brittle
10:51 < djcoin> ok - so I will split it into another file
10:51 < djcoin> anything else ?
10:51 < substack> it's better to duplicate test code than to have tests that are too big
10:51 < substack> seems ok
11:27 < djcoin> substack: PR updated - and by the way you were right, this was leading spaces, did not remember !
11:27 < substack> published 0.1.1
11:27 < djcoin> cool :)
11:28 < djcoin> Thanks for all the awesome lib by the way - I guess you are told this often
13:36 < juliangruber> is there a module for public key cryptography in the browser?
13:39 < juliangruber> I want to do a skype like thing with webrtc where users authorize via keypairs
13:50 < juliangruber> oh, there is: http://ats.oka.nu/titaniumcore/js/crypto/readme.txt
14:06 < tanepiper> http://www.w3.org/TR/WebCryptoAPI/
14:06 < tanepiper> (just a working draft)
14:06 < tanepiper> how about http://polycrypt.net/ ?
14:13 < substack> https://github.com/substack/bashful#implemented
14:13 < substack> dominictarr: https://github.com/substack/bashful#implemented
14:15 < substack> I want to use this lib to make a young lady's illustrated primer for computing
14:15 < substack> starting with the shell and then it will show how to write your own commands
14:15 < substack> all filled with adventure and parables
14:16 < dominictarr> yes
14:16 < dominictarr> although, is shell the best place to start?
14:16 < substack> and the materials covered will be enough to understand the entire source code by the end
14:16 < substack> I started at the shell
14:17 < substack> I think the shell is the best place because it frames programming in simple terms
14:17 < dominictarr> oh really
14:17 < substack> programs just take input and produce output
14:17 < dominictarr> yes, using commands to tell the computer what to do
14:17 < substack> yes and commands are simple
14:17 < dominictarr> better error messages would improve things greatly
14:17 < no9> doesn't  zedshaw have a similar approach?
14:18 < substack> and then when the system commands are inadequate for your purposes you have the motivation to write some commands of your own
14:18 < dominictarr> I have to google whenever I try to do something complex with the shell
14:18 < substack> I won't write about complicated things
14:18 < dominictarr> no9: substack yeah, there is a zed shaw web rebels talk where he says that
14:18 < substack> just the basics of pipes, redirects, stdout, and stdin
14:18 < no9> http://cli.learncodethehardway.org/book/ is part of it
14:18 < no9> ??
14:18 < dominictarr> right - thta is the bast parts of the shell
14:19 < dominictarr> the parallelism is interesting too
14:19 < substack> it's like a spellbook that comes with some pre-built spells but mostly empty pages for kids to write their own spells
14:19 < dominictarr> & ; etc
14:19 < dominictarr> { … } & { … }
14:19 < no9> substack I have a 10 year old here for UAT
14:19 < no9> She does all my dojo QA
14:21 < substack> each thing students learn will be embedded in a narrative structure so that they have a reason to learn each new piece
14:22 < substack> it needs to be addictive
16:48 < jjjjohnnny> mikolalysenko: yeah all of that was too advanced for me
16:49 < jjjjohnnny> mikolalysenko: what I am lost on, is where do I get the other array of "imaginary" input
16:49 < jjjjohnnny> i have an array of audio PCM data, what is the other array?
16:49 < jjjjohnnny> the imginary counterpart
18:16 < mbalho> jlord: im refreshing https://github.com/blog all day like mad
18:18 < chapel> mbalho: why is that?
18:18 < mbalho> SECRETS
18:24 < tmcw> hah
18:25 < mbalho> tmcw: WHOA WEIRD the last word i read before i saw you say something in here was 'mapbox' in an email that migurski sent to somewhere
18:25 < mbalho> tmcw: it was as if reading it summoned you
18:25 < tmcw> omnipresence etc
18:36 < juliangruber> substack is away :O
18:57 < mikolalysenko> jjjjohnnny:  just set them all to 0 if you are transforming a real signal
18:57 < mikolalysenko> you still need to allocate memory for them though, since the fft of a real signal will have imaginary components in general
18:58 < isaacs> netsplits at subrub!
18:58 < mikolalysenko> unless of course the signal is symmetric wrt to reflection across each axis
18:58 < mikolalysenko> if you just want a power spectrum, you could do:
18:59 < mikolalysenko> ndfft(1, x ndarray.zeros(x.shape))
18:59 < mikolalysenko> then square each component independently
19:00 < mikolalysenko> I should probably make a module to arithmetic on arrays of complex numbers
19:27 < mbalho> chrisdickinson: if you wanna meet up and hack this week the easiest way is #nerdtracker
19:34 < chrisdickinson> mbalho: awesome, thanks for the heads up
19:35 < chrisdickinson> also, was https://github.com/blog/1502-jekyll-turns-1-0 what you were waiting for?
19:35 < mbalho> nope
19:35 < mbalho> it will be obvious :D
19:42 < mbalho> substack: whoa youre coming to nodepdx?
19:42 < substack> mbalho: yep
19:42 < substack> I arrive on wednesday
19:43 < mbalho> sweet! im already up here
19:46 < substack> git friends: https://www.gittip.com/for/javascript/ https://www.gittip.com/for/node-js/
19:47 < jjjjohnnny> mikolaly1enko: "square each component independently
19:47 < jjjjohnnny> "
19:48 < jjjjohnnny> of the resulting spectrum?
19:48 < jjjjohnnny> each index
19:49 < jjjjohnnny> POLL YOU GUYS:
19:49 < LOUDBOT> OH HEY THERE COMMUNO ANARCHISM
19:49 < jjjjohnnny> i am writing a browser module
19:50 < jjjjohnnny> which lets you write javascript in the browser, that in turns runs inside this module: npmjs.org/packages/jsynth
19:50 < jjjjohnnny> QUESTION IS: should the script the user writes return a function, or module.exports?
19:51 < jjjjohnnny> its for live coding audio DSP BTQ
19:51 < jjjjohnnny> sorry, this module https://npmjs.org/package/jsynth
19:52 < jjjjohnnny> VOTE 0 for script with return statement
19:52 < jjjjohnnny> VOTE 1 for module.exports
19:52 < substack> 0
19:53 < Domenic_> 1
19:55 < jjjjohnnny> VOTE 2 for function declaration of a spcific name ie function synth(){}
20:06 < jjjjohnnny> VOTE WITH UR MOUTHIES
20:06 < LOUDBOT> DHOSS I'LL TRADE YOUR CODING WORK FOR MINE
20:13 < jjjjohnnny> whys my problem here
20:13 < jjjjohnnny> ?
20:13 < jjjjohnnny> i want to contribute to an npm module
20:13 < jjjjohnnny> so I clone the maintainer's repo
20:13 < jjjjohnnny> and it doesn't work like the npm repo did
20:14 < jjjjohnnny> this is why I always go straght to the module itself when I want to edit a module
20:14 < jjjjohnnny> but then it makes me have problems merging with the forked repo
20:14 < jjjjohnnny> b/c, as above, they are not at parity
20:16 < jjjjohnnny> probably i a missing somethning
20:25 < juliangruber> substack: I'm making rsa-json work in the browser :) private keys already work
20:28 < chrisdickinson> mbalho: oh!
20:28 < chrisdickinson> congrats jlord!
20:57 < defunctzombie> substack: what do you mean by non-global way?
20:58 < defunctzombie> substack: I am at a point where I can probably just merge that pull request so they will stop bitching about it
20:58 < defunctzombie> substack: I think using coffeescript and expecting all the tools to support it is stupid
20:58 < defunctzombie> cause they assume that my goal is to make coffeescript work and it isn't
20:59 < defunctzombie> but since the patch is easy, whatever I am tired of the emails from people who don't want to write javascript and don't realize they are using a different language
21:18 < jjjjohnnny> substack: tomorrow noon berkeley
21:25 < tmcw> congrats jlord !
21:25 < tmcw> plz made default issue label colors pantone (c)
21:25 < tmcw> *make
21:27 < juliangruber> tanepiper: webcryptoapi looks sweet, need to check that out
21:30 < mikolalysenko> chrisdickinson:  correct me if I am wrong, but I remember you did some work a while back on pooling buffers/typed arrays.  is that code on npm somewhere?
21:32 < chrisdickinson> mikolalysenko: https://github.com/chrisdickinson/pooled
21:35 < jjjjohnnny> neat
21:36 < mikolalysenko> interesting
21:36 < mikolalysenko> though what I am thinking about is making a common module for allocating typed array buffers
21:37 < mikolalysenko> since creating them is stupidly expensive in v8
21:37 < mikolalysenko> so there would be like a common store for all typed arrays based on size
21:37 < mikolalysenko> and then whenever you need a scratch typed array, you'd just pull one in and return it when you are done
21:38 < mikolalysenko> basically it would be a malloc/free-like implementation
21:38 < mikolalysenko> except using the globals object to keep a common supply of buffers
21:39 < jjjjohnnny> i heard DOM object pooling is important too
21:40 < mikolalysenko> yeah, makes sense
21:40 < jjjjohnnny> its like our uzis weigh a ton
21:40 < chrisdickinson> yeah, that's pretty much what pooled does
21:40 < mikolalysenko> the catch with typed arrays though is that they can be different sizes
21:40 < mikolalysenko> I am thinking make a pool for each power of two
21:40 < mikolalysenko> or something like that
21:41 < mikolalysenko> then when you alloc a buffer, round it up to nextPow2 and return a new typed array of that size
21:41 < mikolalysenko> also when creating a buffer you would allocate a typed array for each of the views preemptively
21:42 < jjjjohnnny> mikolalysenko: that would be especially useful for web worker heavy apps
21:42 < chrisdickinson> the other useful thing: https://github.com/chrisdickinson/bops/blob/master/typedarray/mapped.js + https://github.com/chrisdickinson/bops/blob/master/typedarray/write.js#L29
21:42 < chrisdickinson> since DataView is slow too iirc
21:44 < mikolalysenko> interesting
21:44 < mikolalysenko> so I am thinking of creating an interface where you get an object that simultaneously has all of the typedarray views allocated for it
21:45 < mikolalysenko> so you give the number of bytes and get a buffer with a pointer to each of them
21:45 < mikolalysenko> the alternative though would be to make separate pools for each typed array class
21:45 < mikolalysenko> but that is wasteful, and obviously inefficient
21:46 < mikolalysenko> the other thing you could possibly do is convert the buffer at run time
21:46 < mikolalysenko> but instantiating a typed array even from an array buffer view is slow for no good reason
21:46 < chrisdickinson> DataView would probably be better than multiple Typed Array views
21:46 < mikolalysenko> hmm
21:47 < chrisdickinson> 1 dataview can get or set any shape of data at any byte offset at any endianness
21:47 < mikolalysenko> well, I want to allocate typed arrays of different types
21:47 < chrisdickinson> and it only takes 1 per arraybuffer
21:47 < chrisdickinson> all typed arrays are represented internally by an arraybuffer
21:47 < mikolalysenko> ie, I ask for a temporary uint8array for example
21:47 < mikolalysenko> right
21:47 < chrisdickinson> (i.e., why not deal with all of it in terms of bytes and then do casting at a higher level?)
21:47 < mikolalysenko> yeah, so I was thinking why not just allocate one arraybuffer, then instantiate a bunch of different typed arrays on top of it
21:47 < chrisdickinson> ah
21:48 < chrisdickinson> i'd only do casting on demand
21:48 < chrisdickinson> or just default to always handing back bytes
21:48 < mikolalysenko> hmm
21:48 < mikolalysenko> but then you would have to realloc a typed array for that buffer even if you are hitting the same type each time
21:48 < mikolalysenko> though I wonder how expensive it is
21:49 < mikolalysenko> one sec, let me try a jsperf
21:50 < mikolalysenko> yeah, no good
21:50 < mikolalysenko> here is a benchmark:  http://jsperf.com/realloc-vs-buffer
21:51 < juliangruber> substack defunctzombie_zz: can I force browserify to bundle a certain module? I'm dealing with a lib that does only dynamic require calls
21:51 < chrisdickinson> i'm getting 400k-ish more ops out of buffer reuse than no-reuse
21:52 < mikolalysenko> it is faster, but still has a large overhead
21:52 < mikolalysenko> hmm
21:52 < mikolalysenko> I need to come up with a better test though
21:52 < chrisdickinson> i'm kind of on the side of "hand back a byte array"
21:52 < chrisdickinson> i.e., a Uint8Array
21:53 < chrisdickinson> anything else can just use dataviews
21:53 < mikolalysenko> well, I usually want float arrays for my apps
21:53 < chrisdickinson> or bops
21:53 < mikolalysenko> or experiments
21:53 < chrisdickinson> does Float32Array(12) have a default endianness?
21:53 < mikolalysenko> no clue
21:54 < mikolalysenko> I would assume it is whatever the system endianness is
21:54 < mikolalysenko> probably little endian on x86, on arm maybe something different...
21:56 < Domenic_> endianness of typed arrays is actually a point of debate
21:56 < Domenic_> i think it's system endianness right now
21:56 < Domenic_> they want to standardize on little endian
21:56 < Domenic_> but some people are complaining that would be a big perf hit
21:56 < Domenic_> so fine we'll let it be system endianness for a few years
21:57 < Domenic_> then when there's tons of code that assumes little endianness, forcing the big endian systems to do translation in order to work with that code, we can laugh, say i told you so, and standardize on little endianness
22:00 < mikolalysenko> system endianness makes the most sense
22:01 < mikolalysenko> but mobile is mostly big endian
22:01 < mikolalysenko> while desktop is all little endian
22:02 < juliangruber> it should be all about interoperability
22:03 < mikolalysenko> chrisdickinson:  I just tested it and preallocating arrays wins by a mile
22:03 < mikolalysenko> let me post the code on github
22:05 < mikolalysenko> chrisdickinson:  here is the code  https://github.com/mikolalysenko/typedarray-cache-experiment
22:11 < mikolalysenko> chrisdickinson: writing a quick readme right now to explain what is going on
22:11 < st_luke> isaacs: if trolling is an art, are artists insecure?
22:11 < st_luke> #trololol
22:11 < isaacs> st_luke: probably.
22:12 < isaacs> st_luke: i mean, have you ever MET any artists?
22:13 < mikolalysenko> chrisdickinson:  Ok, this is completely definitive imo:  https://github.com/mikolalysenko/typedarray-cache-experiment
22:13 < mikolalysenko> you have to preallocate a typed array, just returning a buffer doesn't cut it
22:14 < mikolalysenko> in fact, for small arrays it is actually *WORSE* to return a buffer than it is to just realloc the array
22:14 < mikolalysenko> though you could debate the relative merits of cache efficiency, memory leakage, etc.
22:16 < ralphtheninja> isaacs: what's with the discussion on trolling? what happened?
22:18 < isaacs> ralphtheninja: Well, back in 1963, they came up with this new idea for a packet switching network, called ARPANET...
22:18 < isaacs> ralphtheninja: ;)
22:18 < isaacs> ralphtheninja: The Internet happened, that's all :)
22:18 < ralphtheninja> isaacs: haha ok :)
22:21 < jjjjohnnny> isaacs: if you are free tomorrow @ noon you can join us in berkeley at the lab of ad hoc cell network hacker
22:25 < isaacs> jjjjohnnny: i am not free tomorrow at noon, sorry.
22:25 < isaacs> jjjjohnnny: tuesday = go to sf and be in meetings day
22:29 < mikolalysenko> the other option would be to create a separate pool for each typed array class
22:29 < mikolalysenko> so have a pool for floats, ints, etc.
22:30 < mikolalysenko> the downside though is wasting more memory and worse cache performance
22:31 < mikolalysenko> but it would probably work better than the constructing new typed arrays each time
22:31 < mikolalysenko> though the interface would be simpler
22:36 < mikolalysenko> actually, the more I think about it the more that caching just the typed arrays by themself makes sense
22:36 < mikolalysenko> you could probably use them directly with workers for example
22:37 < mikolalysenko> and the interface would be much cleaner, just malloc/free
22:37 < mikolalysenko> AND you could offload some of the size calculations too
22:52 < calvinfo_> has anyone had issues piping gunzip with new streams?
22:52 < calvinfo_> or can maybe tell me what I'm doing wrong: https://gist.github.com/calvinfo/e9c60f8161ff0bbc45a1
22:52 < calvinfo_> I'm a bit confused why only one of these methods works
22:53 < mikolalysenko> Ok, I added an array pooling cache to the experiments.  https://github.com/mikolalysenko/typedarray-cache-experiment
22:53 < defunctzombie> juliangruber: substack: no way to force iirc, you should probably fix the module (depending on what the dynamic things are for)
22:54 < mikolalysenko> and fixed a bug in the buffer cache
22:54 < defunctzombie> juliangruber: in 98% of cases dynamic loading is not the correct thing to do, but it can vary based on what is going on
22:55 < juliangruber> defunctzombie: https://github.com/digitalbazaar/forge/blob/master/js/pki.js#L3172-L3229
22:55 < juliangruber> defunctzombie: I think I'll refactor out the only the parts that I need into seperate modules
23:00 < defunctzombie> juliangruber: sounds like those should just be regular requires
23:00 < defunctzombie> juliangruber: they are trying to do their own "env" detection which is wrong approach
23:00 < defunctzombie> this file is out of control
23:00 < defunctzombie> jesus
23:01 < juliangruber> defunctzombie: I think if you want requirejs and amd support as well there's no other choice, right?
23:01 < defunctzombie> juliangruber: I thought UMD (which is what browserify uses) supports all
23:02 < juliangruber> defunctzombie: AMD does async requires for those cases where you don't bundle up everything into one file
23:02 < juliangruber> I don't see how that would work with sync require()
23:02 < defunctzombie> amd is stupid
23:02 < defunctzombie> just don't use it in the module system
23:03 < defunctzombie> it is not needed
23:03 < defunctzombie> if you want several files for cache reasons, then use the multibundle stuff
23:03 < juliangruber> exactly my opinion, but I don't want to put in all the effort necessary to make them switch
23:03 < juliangruber> I'll just publish their shit as seperate modules, end of story :)
23:16 < jlord> chrisdickinson twcw: Thanks! I'm so excited!
23:22 < mikolalysenko> Ok, I went and did it:  https://github.com/mikolalysenko/typedarray-pool
23:44 < substack> juliangruber: AWESOME
23:44 < substack> @ rsa-json
23:44 < substack> I'm making bash work in the browser between other things
23:46 < st_luke> juliangruber: that is a very large repo
23:55 < mikolalysenko> damn it.  I just realized that all my repos are missing license files...
23:55 < mbalho> lol
23:55 < mikolalysenko> so, I am thinking that I will have to write a script to walk through my github directory and add one/do a push
23:55 < mbalho> itd be cool to have a github bulk editor
23:55 < mikolalysenko> which is going to create one gigantic cluster fuck
23:56 < mikolalysenko> yeah
23:56 < mbalho> mikolalysenko: you shoudl gplv3 just to mess with people
23:56 < mikolalysenko> haha, no.
23:57 < mikolalysenko> hmm
23:57 < mikolalysenko> do I have to republish a module on npm if I fix a license file?
23:57 < mikolalysenko> if so it is going to create a gigantic pile of crap...
23:58 < mbalho> as long as they have repo liinks i wouldnt bother
23:59 < mikolalysenko> ok
23:59 < mikolalysenko> but I still ought to update all the repos, at least for posterity
--- Log closed Tue May 14 00:00:09 2013