| 00:00:00
| * ircretary | quit (Remote host closed the connection) |
| 00:00:09
| * ircretary | joined |
| 00:00:21
| <mikolalysenko> | substack: it isn't actually side effects that are the problem |
| 00:00:32
| <mikolalysenko> | it is basically the lexical scoping of the closure |
| 00:00:42
| <mikolalysenko> | like if it uses variables from an outside scope, then you can't inline it |
| 00:00:52
| <substack> | I mean it could be made into an automatic optimization pass like `| fastify` |
| 00:01:03
| <mikolalysenko> | oh, that could work |
| 00:01:07
| <substack> | like uglify, but for moar fasters |
| 00:01:11
| <mikolalysenko> | that's just generic partial evaluation |
| 00:01:21
| <mikolalysenko> | the downside though is that excessive inlining = bigger code |
| 00:01:37
| <mikolalysenko> | but doing it at run time for hot routines like this seems like a reasonable trade off |
| 00:01:46
| <substack> | gzip is good at optimizing for that kind of redundancy though |
| 00:02:01
| <mikolalysenko> | to some level, but you will get lots of repeated variables when you inline stuff |
| 00:02:14
| <mikolalysenko> | and you have to call it off when you get recursive routines and so on |
| 00:02:46
| <mikolalysenko> | I think that as it gets more generic it becomes harder to just speed up code beyond what the vm already can do |
| 00:03:14
| <mikolalysenko> | however for this routine it definitely does give an advantage since the implementation of bind() in v8 is totally half assed |
| 00:05:14
| <mikolalysenko> | what I am thinking about using it for is to speed up some meshing routines |
| 00:05:30
| <mikolalysenko> | where I have a bunch of different ad-hoc config parameters that really need to be higher order functions |
| 00:05:38
| <mikolalysenko> | and calling them over and over is really slow/wasteful |
| 00:06:01
| <mikolalysenko> | so I figure why not inline them? |
| 00:08:01
| * kevinohara80 | quit (Remote host closed the connection) |
| 00:08:45
| <mikolalysenko> | would be nice to have a module that can just obliterate parse trees into ssa form though... |
| 00:09:06
| <mikolalysenko> | I had to write a simple version of that for this module, but it was a bit tedious... |
| 00:09:21
| <mikolalysenko> | https://github.com/mikolalysenko/specialize/blob/master/lib/specialize-function.js#L57 |
| 00:09:25
| <mikolalysenko> | pretty ugly... |
| 00:19:22
| * mikeal | joined |
| 00:19:29
| <substack> | mikolalysenko: this spectrogram code was really tiny with ndarray-fft :D |
| 00:19:34
| <substack> | plus isaacs's block-size module |
| 00:19:34
| * st_luke | joined |
| 00:21:20
| <jesusabdullah> | ndarray-fft? That makes me feel warm and fuzzy inside. |
| 00:21:56
| <substack> | jesusabdullah: https://github.com/substack/sillyscope/blob/master/index.js |
| 00:22:43
| <jesusabdullah> | very nice. :) |
| 00:24:20
| <jesusabdullah> | substack: one question: where do the results of the fft go? |
| 00:24:32
| <jesusabdullah> | substack: I'm guessing this call signature is due to in-place being moar fasters |
| 00:24:33
| <substack> | in-place updates |
| 00:24:39
| <substack> | yes |
| 00:24:53
| <jesusabdullah> | substack: so the inputs get transformed into the outputs? |
| 00:24:58
| <substack> | data goes in through the real component and goes out through the imaginary component |
| 00:25:02
| <jesusabdullah> | ahhhh |
| 00:25:05
| <jesusabdullah> | okay |
| 00:25:08
| <substack> | but the reals might also get modified in the computation, I'm not sure |
| 00:25:11
| <jesusabdullah> | mmhmm |
| 00:25:21
| <mikolalysenko> | substack, jesusabdullah : glad you like ndarray-fft |
| 00:25:29
| <jesusabdullah> | i just dig the idea mikolalysenko |
| 00:25:38
| <mikolalysenko> | it is just an in place radix-2 fft with a fall back to the bluestein algorithm |
| 00:25:43
| <niftylettuce> | for any gamers in here... front page of HN "A fantasy league for League of Legends (draftdemacia.com)" |
| 00:25:56
| <mikolalysenko> | though I may go back and add optimized stuff for other sizes/highly composite numbers |
| 00:26:21
| <jesusabdullah> | mikolalysenko: You know I'm a numerics geek XD |
| 00:26:27
| <mikolalysenko> | also it would be neat to eventually look at run time code generation like fftw does it |
| 00:27:19
| * ralphtheninja | quit (Ping timeout: 246 seconds) |
| 00:27:20
| <substack> | I only know how to make ffts give me frequency domain information |
| 00:27:22
| <mikolalysenko> | jesusabdullah: haha, you should check out some of the other stuff for ndarrays. this one I am actually pretty happy with: https://github.com/mikolalysenko/distance-transform?source=c |
| 00:27:42
| <mikolalysenko> | substack: also the imaginary part is not the output value, the result is stored in both the real and imaginary parts |
| 00:28:14
| <mikolalysenko> | also as a protip you can avoid creating the temporary imaginary array if you reuse a typed array, for example from: https://github.com/mikolalysenko/typedarray-pool |
| 00:28:43
| <mikolalysenko> | if you want the magnitude of the fft you can just take the squared modulus of the real/complex channels |
| 00:29:02
| <substack> | "squared modulus" |
| 00:29:14
| <mikolalysenko> | yeah |
| 00:29:19
| <jesusabdullah> | mikolalysenko: the norm? |
| 00:29:21
| <mikolalysenko> | ndarray-complex has stuff to do this: https://github.com/mikolalysenko/ndarray-complex |
| 00:29:27
| <jesusabdullah> | oh sick complex numbers |
| 00:29:29
| <mikolalysenko> | yeah, z * z^t |
| 00:29:38
| <jesusabdullah> | I'll need to find an excuse here |
| 00:29:44
| <jesusabdullah> | to do some of this stuff |
| 00:29:51
| <mikolalysenko> | substack: if you use ndarray-complex.mag it should do what you want |
| 00:30:35
| <mikolalysenko> | here is an example for how to unpack the magnitude into the result into the real part: |
| 00:30:41
| <jesusabdullah> | mikolalysenko: is the real/imaginary inverse what they are in a laplace xform? |
| 00:30:53
| <mikolalysenko> | var cops = require("ndarray-complex"); cops.mag(real, real, imag) |
| 00:31:09
| <mikolalysenko> | jesusabdullah: not quite, laplace transform is the analytic continuation of the fourier transform |
| 00:31:11
| <jesusabdullah> | why two real components? |
| 00:31:20
| <mikolalysenko> | the real channel is being overwritten :) |
| 00:31:22
| <mikolalysenko> | it is a bit tricky |
| 00:31:24
| <jesusabdullah> | mikolalysenko: right, this one's discrete right? |
| 00:31:34
| <substack> | cops be fillin they mags with real and imaginary ammo |
| 00:31:36
| <jesusabdullah> | I mean, I know DFT versus continuous FT |
| 00:31:41
| <mikolalysenko> | I think you could define a discrete laplace transform |
| 00:31:50
| <jesusabdullah> | substack: for DOUBLE the PUNCH |
| 00:31:57
| <jesusabdullah> | Yeah, you can, it's possible |
| 00:31:59
| <jesusabdullah> | hehe |
| 00:32:19
| <mikolalysenko> | the main difference in all the ffts is basically the symmetry group on which they are acting |
| 00:32:21
| * kirbysayshi | joined |
| 00:32:29
| <mikolalysenko> | dft = discrete cyclic shifts |
| 00:32:38
| <mikolalysenko> | while real fft = continuous shifts of real line |
| 00:32:46
| <jesusabdullah> | mmhmm |
| 00:32:56
| <mikolalysenko> | you can also make other things like continuous ffts for circles |
| 00:32:58
| <jesusabdullah> | shit I need my coffee |
| 00:33:01
| <mikolalysenko> | where it is just 2d rotations |
| 00:33:13
| <mikolalysenko> | there are also weirder things for non-commutative groups |
| 00:33:24
| <mikolalysenko> | like rotations in 3d which split apart functions into wigner-d matrices |
| 00:33:37
| <mikolalysenko> | or when restricted to the sphere you get spherical harmonics |
| 00:33:49
| <jesusabdullah> | mmhmm |
| 00:33:50
| <mikolalysenko> | (which are just wigner matrices mod spin) |
| 00:34:15
| <jesusabdullah> | I have to admit most of my knowledge of these things deals with vibration analysis |
| 00:34:30
| <mikolalysenko> | yeah, though you can use ffts all over the place |
| 00:34:37
| <jesusabdullah> | yeah |
| 00:34:40
| <mikolalysenko> | like in heat transport, em, etc. |
| 00:34:50
| <mikolalysenko> | pretty much anywhere you have a translational symmetry it is applicable |
| 00:34:57
| <jesusabdullah> | yeah, I mean, Fourier was trying to model heat transfer when the fourier transform was invented |
| 00:35:06
| <mikolalysenko> | yeah |
| 00:35:07
| <jesusabdullah> | his model was messed up but the idea was useful |
| 00:35:08
| <jesusabdullah> | iirc |
| 00:35:24
| <mikolalysenko> | but he could have picked any translation invariant differential equation and come to the same conclusion |
| 00:35:33
| <jesusabdullah> | yeah but he picked a good one |
| 00:35:35
| <jesusabdullah> | obviously |
| 00:35:36
| <jesusabdullah> | haha |
| 00:35:45
| <mikolalysenko> | well, maybe not so good if the model was wrong! |
| 00:36:20
| <mikolalysenko> | but the point is he could have looked at basically any linear translation invariant differential equation |
| 00:36:21
| <mikolalysenko> | and gotten the same conclusion |
| 00:37:02
| <mikolalysenko> | the underlying reason for this is that fourier waves are the invariant under translations |
| 00:37:17
| <mikolalysenko> | and so if an operator is invariant under translations, then its spectrum is also invariant too |
| 00:37:32
| <mikolalysenko> | and since these things split apart into complex conjugate pairs (ie sine/cosine waves) |
| 00:37:45
| <mikolalysenko> | knowing that an operator is translation invariant automatically tells you its eigen basis! |
| 00:37:58
| <jesusabdullah> | EIGEN SCHMEIGEN |
| 00:37:58
| <LOUDBOT> | TEST DRIVEN AGILE WATERFALL SCRUMM |
| 00:38:01
| <mikolalysenko> | (ie it will be the fourier basis) |
| 00:38:07
| <jesusabdullah> | SINGULAR VALUES IS HOW I ROLL |
| 00:38:07
| <LOUDBOT> | ON THE REGULAR BROTHER |
| 00:38:09
| <jesusabdullah> | giddyup |
| 00:38:19
| <jesusabdullah> | (that's not true) |
| 00:38:26
| <mikolalysenko> | replace eigen with invariant subspace and it is the same thing in both cases |
| 00:38:33
| <jesusabdullah> | but yes this is all coming back to me |
| 00:38:44
| <substack> | I have no idea what any of this means |
| 00:38:52
| <jesusabdullah> | so, like, substack, natural modes |
| 00:38:56
| <jesusabdullah> | you know these, yes? |
| 00:39:10
| <substack> | I just did var comps = complex.mag(reals, reals, imags) and now I get an EPIPE |
| 00:39:11
| <jesusabdullah> | They're kiiiinda like eigenvectors except they're functions |
| 00:39:14
| <substack> | so whatevs, it's probably fine |
| 00:39:34
| <mikolalysenko> | substack: the result gets written back into reals |
| 00:39:49
| <mikolalysenko> | it doesn't store a value in comps |
| 00:40:21
| <mikolalysenko> | here is the source for mag, maybe it makes sense: https://github.com/mikolalysenko/ndarray-complex/blob/master/cops.js#L252 |
| 00:40:39
| <mikolalysenko> | actually it does write reals back to comps... |
| 00:43:03
| <substack> | ok this output looks much more legit now |
| 00:46:36
| * defunctzombie_zz | changed nick to defunctzombie |
| 00:48:31
| * jxson_ | joined |
| 00:49:44
| * nicholasf | joined |
| 00:50:58
| * jxson | quit (Ping timeout: 245 seconds) |
| 00:51:37
| * jxson_ | quit (Read error: Connection reset by peer) |
| 00:52:03
| * jxson | joined |
| 00:53:31
| * mmckegg | joined |
| 00:54:31
| * nicholasf | quit (Ping timeout: 276 seconds) |
| 01:00:27
| * kevino80 | joined |
| 01:01:33
| * thl0 | joined |
| 01:02:22
| <jesusabdullah> | I should do something today |
| 01:02:29
| <jesusabdullah> | I got my webserver where I want it |
| 01:02:33
| <jesusabdullah> | Job hunt is up to snuff |
| 01:04:22
| <mikolalysenko> | you could write a module for ndarrays? |
| 01:05:08
| <mikolalysenko> | an easy thing would be something to calculate derivatives, probably using ndarray-fft/cwise together |
| 01:05:10
| <owen1> | how do i modularize a decent-size website using node? not only in terms of commonJS modules but also deployable units - I want to be able to deploy small parts of my website seperatly. it's a big ruby site that i might need to convert to node + angular. can i create small projects and put each one inside a frame? |
| 01:06:45
| <jesusabdullah> | mikolalysenko: why not just finite difference? |
| 01:06:55
| <jesusabdullah> | mikolalysenko: do you have an rk4 method implemented? |
| 01:07:07
| <substack> | owen1: create tiny http servers that talk to each other |
| 01:07:21
| <mikolalysenko> | jesusabdullah: nope! haven't gotten around to it yet |
| 01:07:32
| <mikolalysenko> | also an automatic differentiation tool would be cool |
| 01:07:46
| * mikeal | quit (Quit: Leaving.) |
| 01:07:49
| <mikolalysenko> | it could even use specialize to speed things up |
| 01:08:08
| * joliss | quit (Quit: joliss) |
| 01:08:25
| <jesusabdullah> | mikolalysenko: care to elaborate? |
| 01:08:30
| <jesusabdullah> | mikolalysenko: also, why not finite difference? |
| 01:08:41
| <mikolalysenko> | two separate issues |
| 01:08:56
| <owen1> | substack: are u talking about using iframes? please elaborate. i am excited! i don't want to replace i giant ruby mess with a giant js mess (: |
| 01:09:04
| <mikolalysenko> | for the second one, fft derivatives are more accurate (at least for periodic or reflected boundary conditions) |
| 01:09:16
| <jesusabdullah> | oh, good to know |
| 01:09:19
| <mikolalysenko> | since you spectral convergence rates in the sinc basis |
| 01:09:24
| <jesusabdullah> | hmmm |
| 01:09:28
| <jesusabdullah> | link to algorithm? |
| 01:09:31
| <mikolalysenko> | it ends up being exponentially better than finite differences |
| 01:09:43
| <mikolalysenko> | don't have a link to an algorithm but can link to a book that explains the theory |
| 01:09:44
| <jesusabdullah> | that's cool |
| 01:09:53
| <mikolalysenko> | implementing is simple though, just multiply by frequency |
| 01:09:59
| <jesusabdullah> | or at least a name for the algorithm, wikipedia probably has what I need to know |
| 01:10:26
| <mikolalysenko> | here is the wiki page for the multipliers: http://en.wikipedia.org/wiki/Multiplier_(Fourier_analysis)#Further_Examples |
| 01:10:43
| <mikolalysenko> | in psuedo code it looks like: |
| 01:10:44
| <jesusabdullah> | cool |
| 01:10:48
| <substack> | owen1: don't use iframes. ever. |
| 01:10:50
| <mikolalysenko> | loop over all frequencies, multiply by index |
| 01:10:55
| <mikolalysenko> | or frequency |
| 01:11:07
| <jesusabdullah> | mmhmm |
| 01:11:16
| <jesusabdullah> | so what's this automatic differentiation you have in mind? |
| 01:11:18
| <owen1> | substack: ahahah so how do i create many deployable website that consist one site? |
| 01:11:39
| <mikolalysenko> | automatic differentiation would be just write a function that takes a function then does finite differences to calculate a derivative |
| 01:11:52
| <mikolalysenko> | that could probably be sped up by inlining the function using specialize() |
| 01:12:13
| <substack> | owen1: https://github.com/substack/ploy |
| 01:12:14
| <mikolalysenko> | a more sophisticated idea though would be to try improving on this using actual static analysis |
| 01:12:22
| <jesusabdullah> | mikolalysenko: oh I see, pass a function not values |
| 01:12:29
| <mikolalysenko> | jesusabdullah: yeah |
| 01:12:35
| <owen1> | substack: diving in. [email protected] |
| 01:12:39
| <owen1> | THANKS |
| 01:12:40
| <jesusabdullah> | mikolalysenko: yeah I dig that idea |
| 01:12:47
| <substack> | owen1: and have your http servers talk to each others apis |
| 01:12:55
| <mikolalysenko> | jesusabdullah: it could also be used to do root finding and optimization too |
| 01:13:10
| <mikolalysenko> | and there isn't really anything on npm that already does it |
| 01:13:14
| <owen1> | LOUDBOT WHERE R U |
| 01:13:14
| <LOUDBOT> | BUU IS A FAILED HUMAN BECAUSE HE DOESN'T LIKE BAGELS |
| 01:13:48
| <jesusabdullah> | mikolalysenko: do you have a newton method? |
| 01:14:01
| <mikolalysenko> | jesusabdullah: nope |
| 01:14:06
| <owen1> | substack: talk to each other using dnode? or simple http request/response or depends on the need |
| 01:14:11
| <mikolalysenko> | though I did implement the weierstrass method for finding polynomial roots |
| 01:14:20
| <mikolalysenko> | https://npmjs.org/package/durand-kerner |
| 01:14:31
| <jesusabdullah> | mikolalysenko: also I see how the multipliers work I think, basically you take the fft and then dot that with some f(fft) ? |
| 01:14:36
| <mikolalysenko> | which is kind of like newton's method except it searches at multiple points |
| 01:14:46
| <mikolalysenko> | jesusabdullah: yeah, that's the basic idea |
| 01:14:58
| <mikolalysenko> | here is a simplish explanation: |
| 01:15:02
| <jesusabdullah> | oh, not dot, per-element timesing |
| 01:15:17
| <mikolalysenko> | d ifft( f(x) ) = ifft( x f(x) ) |
| 01:15:20
| <owen1> | "note ploy only works on node 0.8 right now" |
| 01:15:32
| <mikolalysenko> | yeah you multiply by the frequency |
| 01:15:57
| <mikolalysenko> | it is easy to prove it works, just start from the inverse fourier transform and take a derivative |
| 01:16:04
| <jesusabdullah> | oh, that's really reasonable |
| 01:16:07
| <jesusabdullah> | yeah |
| 01:16:37
| <mikolalysenko> | since the derivative variable is independent of the domain of integration you can pull it inside |
| 01:16:39
| <jesusabdullah> | also imo newton method is for optimisation |
| 01:16:43
| <mikolalysenko> | anyway I got to talk to my advisor |
| 01:16:46
| <jesusabdullah> | alright |
| 01:16:49
| <jesusabdullah> | I'm gonna start playing |
| 01:17:54
| <mbalho> | CHALLENGE: how to implement: upload a js file with require()s + list of needed deps @ specific versions and receive a browserified bundle of the file + deps |
| 01:18:43
| * kirbysayshi | quit (Quit: Linkinus - http://linkinus.com) |
| 01:18:45
| <jesusabdullah> | mbalho: I've implemented something like that before, was thinking of doing it again |
| 01:19:07
| <mbalho> | jesusabdullah: it would be really useful to me for this app i'm writing for kids http://voxel-creator.jit.su/ |
| 01:19:14
| <jesusabdullah> | mbalho: my implementation had you POST an index.js and return a bundle, with caching w/ couchdb |
| 01:19:26
| * mmckegg | quit (Quit: mmckegg) |
| 01:19:27
| <jesusabdullah> | mbalho: can you think of a better API? A more general one maybe? |
| 01:19:37
| <mbalho> | jesusabdullah: i need to be able to also send a package.json or at least a list of versions of modules |
| 01:19:41
| <jesusabdullah> | mbalho: also best way to make reusable component? |
| 01:19:52
| <mbalho> | jesusabdullah: module.exports = function(req, res) |
| 01:19:54
| <jesusabdullah> | mbalho: been thinking about making people post a tarball of the project |
| 01:20:03
| <mbalho> | jesusabdullah: tarballs are too hard to maek in the browser |
| 01:20:04
| <jesusabdullah> | mbalho: I'll probably add optional next |
| 01:20:09
| <mbalho> | jesusabdullah: JSON should work though |
| 01:20:09
| <jesusabdullah> | mbalho: yeah was my thinking |
| 01:20:18
| <jesusabdullah> | mbalho: multipart? |
| 01:20:23
| <mbalho> | jesusabdullah: noooo multipart sucks |
| 01:20:26
| <jesusabdullah> | mbalho: maybe support a few approaches |
| 01:20:48
| <mbalho> | jesusabdullah: { file: "require('foobar') blah blah", dependencies: {"foobar": "0.2.4"}} |
| 01:20:57
| <jesusabdullah> | mbalho: aha |
| 01:21:17
| <jesusabdullah> | mbalho: okay so after I hack together this differentiation lib I'll dust off the ol' browserify-cdn |
| 01:21:29
| <jesusabdullah> | oh, question: Is leveldb a good idea for caching these y/n |
| 01:21:35
| <mbalho> | jesusabdullah: yes |
| 01:21:36
| <jesusabdullah> | probably faster n' couchdb |
| 01:21:39
| <jesusabdullah> | word |
| 01:21:41
| <jesusabdullah> | this will be fun |
| 01:22:35
| <mbalho> | jesusabdullah: the way voxel-creator works right now is the server has the newest version of all the modules installed |
| 01:22:51
| <mbalho> | jesusabdullah: so when i upgrade the server it installs the latest version but taht breaks all the old scripts people wrote |
| 01:23:03
| <mbalho> | jesusabdullah: so i realized i need to be able to let users peg versions essentially |
| 01:23:20
| <jesusabdullah> | aha |
| 01:23:28
| <jesusabdullah> | yeah, this will be a fun little project I think |
| 01:24:08
| <mbalho> | i think itll be really useful to front end use cases for browserify too |
| 01:24:24
| <jesusabdullah> | Yeah, like I said I've built this twice |
| 01:24:30
| <jesusabdullah> | it used to be on nodejitsu but, y'know |
| 01:24:34
| <jesusabdullah> | wasn't gonna pay no three fiddy |
| 01:24:39
| <jesusabdullah> | I'll put it back up on jesusabdullah.net |
| 01:25:01
| <jesusabdullah> | also v1 was no-framework hack, v2 was written on lil' flatty |
| 01:25:06
| <jesusabdullah> | I wanna get away from that |
| 01:25:13
| <mbalho> | yea |
| 01:25:21
| <mbalho> | use openshift |
| 01:25:24
| <jesusabdullah> | mbalho: can you point me to some useful libraries for doing this kinda thing? |
| 01:25:27
| <mbalho> | https://github.com/ryanj/nodejs-custom-version-openshift#nodejs-on-openshift |
| 01:25:31
| <jesusabdullah> | mbalho: I have my own vps :) |
| 01:25:33
| <mbalho> | jesusabdullah: for doing what? |
| 01:25:42
| <mbalho> | jesusabdullah: openshift is like vpa + paas |
| 01:25:43
| <jesusabdullah> | leveldb stuff, don't even know where to start |
| 01:25:50
| <mbalho> | jesusabdullah: oh just require('levelup') |
| 01:26:00
| <jesusabdullah> | aha |
| 01:26:03
| <jesusabdullah> | sounds good |
| 01:26:12
| <jesusabdullah> | any sick addons/related libs or whatever I should know about? |
| 01:26:55
| <mbalho> | umm depends https://github.com/rvagg/node-levelup/wiki/Modules#plugins |
| 01:27:26
| <jesusabdullah> | cool, cool |
| 01:27:32
| <jesusabdullah> | I've been in my own tiny ecosystem for a while here |
| 01:27:40
| <jesusabdullah> | haven't had an opportunity to branch out for a while |
| 01:32:42
| <jesusabdullah> | mikolalysenko: so I think I need a copy of an ndarray. Does that sound right? Also since I'm bugging you how do I do that? |
| 01:32:51
| <jesusabdullah> | mikolalysenko: I know in-place is moar fasters |
| 01:33:45
| <jesusabdullah> | mikolalysenko: also I multiply with complex components yeah? Is there a lib for that? |
| 01:34:21
| * jxson | quit (Remote host closed the connection) |
| 01:35:54
| * kirbysayshi | joined |
| 01:40:39
| * chilts | quit (Ping timeout: 240 seconds) |
| 01:43:03
| * chilts | joined |
| 01:43:41
| <jesusabdullah> | shit browserify 1.0'd |
| 01:43:52
| <jesusabdullah> | I have to figure out how to do this build stuff now |
| 01:47:53
| * chilts | quit (Ping timeout: 240 seconds) |
| 01:48:10
| * jaz303 | quit (Ping timeout: 246 seconds) |
| 01:48:18
| * joliss | joined |
| 01:50:07
| * jaz303 | joined |
| 01:53:42
| * chilts | joined |
| 01:54:55
| * dominictarr | quit (Quit: dominictarr) |
| 01:54:57
| <jesusabdullah> | Is there something out that buffers a readable stream? |
| 01:55:22
| <jesusabdullah> | Like, req.pipe(bufferStream(function (err, body) { /* req has ended, here is my body */ }); |
| 01:55:25
| <jesusabdullah> | ? |
| 01:56:40
| <substack> | mikolalysenko: http://substack.net/images/sillyscope_spectrogram.png |
| 01:56:54
| <substack> | jesusabdullah: concat-stream |
| 01:57:25
| <jesusabdullah> | sick |
| 01:57:30
| * kevino80 | quit (Read error: Connection reset by peer) |
| 01:58:08
| * chilts | quit (Ping timeout: 260 seconds) |
| 01:59:12
| * chilts | joined |
| 01:59:44
| <jesusabdullah> | substack: how do you do POST parsing based on content-type? Is there a module for that? |
| 01:59:51
| <jesusabdullah> | I guess you wouldn't need one |
| 02:00:08
| <substack> | why? |
| 02:00:15
| <jesusabdullah> | Why?? |
| 02:00:18
| <substack> | just tell people to POST the right kind of thing |
| 02:00:26
| <jesusabdullah> | What if I want to be really flexible? |
| 02:00:35
| <substack> | to what end? |
| 02:00:41
| <jesusabdullah> | for awesome and ease of use |
| 02:00:41
| <substack> | json xor x-www-form-urlencoded |
| 02:00:53
| <jesusabdullah> | see why not do both? |
| 02:00:55
| <substack> | both is not easier |
| 02:00:58
| <substack> | it's just surprising |
| 02:01:00
| <substack> | in a bad way |
| 02:01:02
| * mikeal | joined |
| 02:01:03
| <jesusabdullah> | tssch |
| 02:01:04
| <jesusabdullah> | well |
| 02:01:08
| <jesusabdullah> | you're lucky I'm feeling lazy |
| 02:01:31
| <substack> | or sometimes POSTs should just be text blobs |
| 02:01:33
| <substack> | or binary blobs |
| 02:01:53
| <substack> | don't make me dick around with mime types just to send an API some data in a format that it already is going to be expecting a certain way |
| 02:02:00
| <substack> | that's not very considerate! |
| 02:02:07
| <jesusabdullah> | tssch |
| 02:02:08
| * kevino80 | joined |
| 02:02:13
| <substack> | I hate having to do this: -H 'accept: application/json' |
| 02:02:19
| <substack> | looking at YOU, couchdb |
| 02:02:23
| <jesusabdullah> | yeah well |
| 02:02:37
| <jesusabdullah> | what if I want to take npm tarballs as well as json blobs? then what? |
| 02:02:54
| <substack> | just make separate endpoints for each kind of thing |
| 02:02:57
| <substack> | that's much nicer |
| 02:03:08
| <substack> | people get so RESTy they fall asleep |
| 02:03:50
| <substack> | did you see what I did there, that inference did not follow but it was PLAYFUL with LANGUAGE |
| 02:03:57
| <jesusabdullah> | YES I DID |
| 02:03:58
| <LOUDBOT> | I HAVE NOW FOUND OUT WHY DESIGNERJEAN IS AN IDIOT: HE'S A MANAGER ATTEMPTING TO PROGRAM |
| 02:04:04
| * chilts | quit (Ping timeout: 276 seconds) |
| 02:04:19
| <jesusabdullah> | WELL I suppose I'll consider your approach! |
| 02:06:03
| <substack> | having a server tell me 'no content-type specified' is like when some form gets rejected by some bureaucrat for not having a phone number |
| 02:09:40
| * st_luke | quit (Remote host closed the connection) |
| 02:10:44
| <chapel> | substack: sounds like you are contradicting yourself, if you support no content type header, than you have to be flexible |
| 02:10:54
| * _kirbysayshi | joined |
| 02:10:54
| <chapel> | at least figure out what the content is, to know its wrong |
| 02:10:57
| <jesusabdullah> | No chapel, there are a few ways to do this |
| 02:11:16
| <jesusabdullah> | chapel: either don't enforce the content-type but enforce that JSON.parse works and document that it expects JSON |
| 02:11:29
| <jesusabdullah> | chapel: or enforce content-type even if the JSON.parse would have worked |
| 02:12:07
| <jesusabdullah> | chapel: or support multiple parse methods based on content-type and/or intelligent guessing |
| 02:12:40
| <chapel> | I guess the simplest way is just return an error, always |
| 02:12:41
| <chapel> | :) |
| 02:12:57
| <chapel> | keep them guessing |
| 02:13:03
| <jesusabdullah> | haha |
| 02:13:29
| <substack> | chapel: use separate paths |
| 02:13:30
| * kirbysayshi | quit (Ping timeout: 240 seconds) |
| 02:13:47
| <substack> | only support one kind of input on each path |
| 02:13:51
| <substack> | much nicer |
| 02:15:04
| <chapel> | substack: while I agree to a certain point, if you are dealing with browsers too, its a harder problem |
| 02:15:18
| <chapel> | not all browsers are built the same :( |
| 02:15:29
| <jesusabdullah> | Yeah, it's nice to be able to post JSON but it's also nice to just do a browser POST and know it won't explode on you |
| 02:15:38
| <jesusabdullah> | but you can mitigate this, yes, by having two paths, one for each |
| 02:16:27
| <substack> | paths are much more explicit than headers |
| 02:17:04
| * chilts | joined |
| 02:22:23
| * chilts | quit (Ping timeout: 240 seconds) |
| 02:24:00
| * kevino80 | quit (Remote host closed the connection) |
| 02:26:46
| * mmckegg | joined |
| 02:28:11
| * mikeal | quit (Quit: Leaving.) |
| 02:30:07
| <mikolalysenko> | jesusabdullah: yeah, there are libraries to do all those things |
| 02:30:16
| <mikolalysenko> | jesusabdullah: (sorry for taking so long to respond was in a skype call) |
| 02:30:21
| <jesusabdullah> | mikolalysenko: no sweat |
| 02:30:53
| <mikolalysenko> | jesusabdullah: here are the simple libraries: https://github.com/mikolalysenko/ndarray-complex, https://github.com/mikolalysenko/ndarray-ops |
| 02:31:24
| <mikolalysenko> | jesusabdullah: also this example may help: https://github.com/mikolalysenko/cwise#apply-a-stencil-to-an-array |
| 02:31:34
| <jesusabdullah> | cool I'll take a look in one sec |
| 02:31:38
| <mikolalysenko> | jesusabdullah: that shows how to apply a laplace filter to an image |
| 02:32:05
| <mikolalysenko> | jesusabdullah: also this shows how to apply different linear filters/convolutions https://github.com/mikolalysenko/ndarray-convolve |
| 02:32:13
| <jesusabdullah> | awesome :) |
| 02:32:41
| <mikolalysenko> | jesusabdullah: but for differential ops you probably want something that just uses cwise and loops over the elements to apply a multiplier |
| 02:33:26
| <mikolalysenko> | substack: that looks awesome! |
| 02:33:44
| <mikolalysenko> | substack: might be neat to have something that computes cepstrums of signals for beat detection/voice recognition |
| 02:35:45
| <substack> | what's a cepstrum? |
| 02:37:04
| <jesusabdullah> | https://gist.github.com/jesusabdullah/5718931 Progress so far |
| 02:37:12
| <jesusabdullah> | I feel like half of these things are already being done somewhere |
| 02:37:18
| <jesusabdullah> | if not I need to "spin these out" |
| 02:44:41
| * vitorpacheco | joined |
| 02:44:48
| * jxson | joined |
| 02:47:44
| * chilts | joined |
| 02:50:03
| <jesusabdullah> | mikolalysenko: https://gist.github.com/jesusabdullah/5718971 Look about right? |
| 02:50:11
| * mikolalysenko | quit (Ping timeout: 240 seconds) |
| 02:50:13
| * jxson | quit (Ping timeout: 276 seconds) |
| 02:50:14
| * nicholasf | joined |
| 02:50:16
| <jesusabdullah> | oh dangit |
| 02:54:35
| * nicholasf | quit (Ping timeout: 260 seconds) |
| 02:59:18
| * mikolalysenko | joined |
| 02:59:32
| <mikolalysenko> | substack: cepstrum http://en.wikipedia.org/wiki/Cepstrum |
| 02:59:39
| <mikolalysenko> | basically inverse fourier transform of log spectrum |
| 02:59:53
| <mikolalysenko> | wiki picture explains best: http://en.wikipedia.org/wiki/File:Cepstrum_signal_analysis.png |
| 03:00:16
| <substack> | tape guide written: http://browserling.com:9005/guide/tape |
| 03:00:41
| <substack> | mikolalysenko: oh I saw these in the wisee paper |
| 03:01:29
| <substack> | or just the video |
| 03:01:50
| <jesusabdullah> | okay, takin' a break |
| 03:02:21
| <jesusabdullah> | hmmm, I should probably shell out to npm and browserify here |
| 03:02:25
| * thl0 | quit (Remote host closed the connection) |
| 03:03:04
| * mikeal | joined |
| 03:04:21
| <jesusabdullah> | mikolalysenko: if you get a chance to look at my gist lemme know |
| 03:07:27
| <mikolalysenko> | jesusabdullah: you mean this one? https://gist.github.com/jesusabdullah/5718931 |
| 03:07:35
| <jesusabdullah> | yeah |
| 03:07:40
| <mikolalysenko> | k |
| 03:07:48
| <jesusabdullah> | I'll be writing tests shortly, I just don't know ndarray "idioms" so to speak |
| 03:09:01
| * mikeal | quit (Quit: Leaving.) |
| 03:10:12
| * mikeal | joined |
| 03:13:46
| * mikeal | quit (Client Quit) |
| 03:14:13
| * mikeal | joined |
| 03:16:36
| <mikolalysenko> | jesusabdullah: interesting, but I need to think about it more carefully |
| 03:16:43
| <mikolalysenko> | jesusabdullah: the idea is pretty good though |
| 03:17:16
| <substack> | writing another guide then finishing updating my blog to use hyperstream |
| 03:20:40
| <jesusabdullah> | mikolalysenko: okay sounds good |
| 03:21:27
| * timoxley | joined |
| 03:31:13
| * jcrugzz | quit (Ping timeout: 240 seconds) |
| 03:46:37
| * fallsemo | joined |
| 03:49:29
| * mikeal | quit (Quit: Leaving.) |
| 03:52:27
| * mikolalysenko | quit (Ping timeout: 260 seconds) |
| 04:07:06
| <jesusabdullah> | Okay I've put off the question of api up until now |
| 04:07:53
| <jesusabdullah> | I need either browserify options or sane defaults, a list of js files to consider and a package.json |
| 04:11:53
| * dguttman | quit (Ping timeout: 240 seconds) |
| 04:11:59
| <timoxley> | substack it looks like you have to do a lot of manual work to make trumpet… work |
| 04:13:04
| <substack> | timoxley: html is really messy |
| 04:17:13
| * harrow` | changed nick to harrow |
| 04:18:54
| * timoxley | quit (Quit: Computer has gone to sleep.) |
| 04:19:45
| * mikeal | joined |
| 04:23:41
| * mikolalysenko | joined |
| 04:33:06
| * jcrugzz | joined |
| 04:36:42
| * jxson | joined |
| 04:50:45
| * nicholasf | joined |
| 04:50:53
| * nicholasf | quit (Read error: Connection reset by peer) |
| 04:51:07
| * dguttman | joined |
| 04:51:09
| * nicholasf | joined |
| 04:55:23
| * dguttman | quit (Ping timeout: 240 seconds) |
| 05:09:29
| * nk109 | joined |
| 05:13:59
| <jesusabdullah> | oh yeah, api for this thing |
| 05:14:20
| * nk109 | quit (Client Quit) |
| 05:20:59
| * dguttman | joined |
| 05:26:13
| * dguttman | quit (Ping timeout: 276 seconds) |
| 05:26:49
| * mmckegg | quit (Quit: mmckegg) |
| 05:27:13
| * mmckegg | joined |
| 05:41:07
| * nicholasf | quit (Read error: Connection reset by peer) |
| 05:41:31
| * nicholasf | joined |
| 05:44:56
| <jesusabdullah> | hah this is all sorts of screwy XD |
| 05:46:15
| * defunctzombie | changed nick to defunctzombie_zz |
| 05:47:10
| * joliss | quit (Quit: joliss) |
| 05:47:26
| * mmckegg | quit (Quit: mmckegg) |
| 05:48:14
| * dguttman | joined |
| 05:51:44
| * dguttman_ | joined |
| 05:52:07
| * fallsemo | quit (Quit: Leaving.) |
| 05:52:28
| * dguttman | quit (Ping timeout: 246 seconds) |
| 05:53:45
| * dguttman | joined |
| 05:54:58
| * jxson | quit (Remote host closed the connection) |
| 05:56:46
| * dguttman_ | quit (Ping timeout: 276 seconds) |
| 05:58:55
| * dguttman | quit (Ping timeout: 260 seconds) |
| 06:03:54
| * timoxley | joined |
| 06:13:13
| * shama | quit (Remote host closed the connection) |
| 06:16:23
| * timoxley | quit (Ping timeout: 240 seconds) |
| 06:17:36
| * _kirbysayshi | quit (Quit: Leaving...) |
| 06:21:05
| <mikolalysenko> | substack: I found a pretty terrible problem in falafel : ( |
| 06:21:07
| <mikolalysenko> | https://github.com/substack/node-falafel/issues/17 |
| 06:21:52
| <mikolalysenko> | basically with that bug you can't properly manipulate for-loops in falafel |
| 06:22:03
| <mikolalysenko> | which totally sucks |
| 06:22:16
| <substack> | we can update the update key name |
| 06:22:28
| <substack> | and when the major rolls out switch to a different name |
| 06:23:44
| <mikolalysenko> | yeah, my current work around is a bit awkward |
| 06:23:58
| <mikolalysenko> | I am basically monkey patching a new field called _update into the parent node of anything which happens to be the update field of a forstatement |
| 06:24:11
| <mikolalysenko> | it is not pretty though |
| 06:26:47
| <substack> | "updater" |
| 06:27:36
| <Raynos> | dominictarr, creatonix: https://github.com/Raynos/continuable-generators#continuable-generators |
| 06:27:52
| <mikolalysenko> | well, I suggested rewrite() which I think is descriptive and doing a ctrl-f doesn't show up on the spider monkey page |
| 06:28:33
| <mikolalysenko> | could probably come up with more names using a thesaurus |
| 06:29:52
| * timoxley | joined |
| 06:31:02
| <jesusabdullah> | mikolalysenko: I realized I was trying to test differentiation as though it was finite differencing (derp) |
| 06:31:08
| <jesusabdullah> | mikolalysenko: I'm more rusty than I thought XD |
| 06:31:34
| <jesusabdullah> | mikolalysenko: but I did write a one-dimensional diff tool https://gist.github.com/jesusabdullah/5719702 |
| 06:34:47
| <mikolalysenko> | jesusabdullah: it is not a bad start, but the cwise call should not be nested |
| 06:35:07
| <mikolalysenko> | otherwise it will recompile the macro each time the function gets called which is kind of slow |
| 06:38:29
| * dguttman | joined |
| 06:38:49
| <jesusabdullah> | mikolalysenko: oh derp |
| 06:38:58
| <jesusabdullah> | mikolalysenko: not used to thinking about how to write fast javascript |
| 06:39:38
| <substack> | waxing philosophic http://www.reddit.com/r/node/comments/1fr5ha/what_ide_do_you_all_use_if_any/cad7dx7 |
| 06:41:11
| * dguttman_ | joined |
| 06:43:31
| <guybrush> | substack: vim isnt a tiny module, end-user-products cant be tiny modules - they dont do 1 thing well, they try to make the user happy |
| 06:43:34
| * dguttman | quit (Ping timeout: 276 seconds) |
| 06:43:55
| <guybrush> | though this is just my opinion, im sure you disagree :p |
| 06:44:07
| <substack> | I don't care about end-users |
| 06:44:16
| <substack> | vim isn't a module, it's a text editor |
| 06:44:18
| <guybrush> | mh you are the end-user isnt it? |
| 06:44:22
| <substack> | but it only concerns itself with editing text |
| 06:44:22
| <guybrush> | i mean you use vim |
| 06:44:46
| * dguttman | joined |
| 06:44:54
| <substack> | not with being a fancy integrated development environment where you can click a button to compile and set breakpoints etc |
| 06:45:04
| <guybrush> | right |
| 06:45:23
| * dguttman_ | quit (Ping timeout: 240 seconds) |
| 06:45:27
| <guybrush> | but there are people who are more productive in such environments |
| 06:45:51
| * defunctzombie_zz | changed nick to defunctzombie |
| 06:46:00
| <guybrush> | but i really see your point with tiny modules |
| 06:46:26
| <mikolalysenko> | there is a balance between modules and getting things done |
| 06:46:43
| <mikolalysenko> | at some point you just say "fuck it" then write the last few miles with hacks |
| 06:46:47
| <mikolalysenko> | and that is how you make apps |
| 06:46:52
| <guybrush> | :D |
| 06:47:17
| <mikolalysenko> | as you get more and better modules you (hopefully) have to do the less often |
| 06:47:40
| <substack> | mbalho: will this be enough? https://github.com/mikeal/nodeconf2013/commit/20d8c5ac2cd3211bf019e68ea7527722d1661ec1 |
| 06:47:53
| * nicholasf | quit (Read error: Connection reset by peer) |
| 06:48:20
| * nicholasf | joined |
| 06:48:53
| * dguttman | quit (Ping timeout: 240 seconds) |
| 06:49:27
| <substack> | oh hey I bet the lot of you can't even see that link |
| 06:55:32
| * kirbysayshi | joined |
| 06:56:08
| * defunctzombie | changed nick to defunctzombie_zz |
| 07:00:55
| * Wraithan | joined |
| 07:03:33
| * stagas | joined |
| 07:05:25
| * jxson | joined |
| 07:06:17
| * dguttman | joined |
| 07:10:19
| * jxson | quit (Ping timeout: 260 seconds) |
| 07:10:24
| * dguttman | quit (Ping timeout: 240 seconds) |
| 07:12:39
| * timoxley | quit (Ping timeout: 260 seconds) |
| 07:29:44
| * kirbysayshi | quit (Quit: Leaving...) |
| 07:32:09
| * dguttman | joined |
| 07:33:29
| * dominictarr | joined |
| 07:34:54
| * mikolalysenko | quit (Ping timeout: 240 seconds) |
| 07:36:13
| <Wraithan> | What do people use to use jade in their browserified js? |
| 07:36:25
| * dguttman | quit (Ping timeout: 246 seconds) |
| 07:36:29
| <Wraithan> | tried jadify and browserijade and ran into issues with both |
| 07:36:35
| <Wraithan> | both appear unmaintained |
| 07:37:11
| <jesusabdullah> | no idea, haven't used jade, well, I tried using it once and didn't like it |
| 07:37:15
| <substack> | I use html |
| 07:38:01
| <substack> | mostly https://github.com/substack/hyperstream |
| 07:38:29
| <jesusabdullah> | honestly I'm an ejs kinda person left to my own devices |
| 07:38:29
| <substack> | with some https://github.com/substack/hyperglue and https://github.com/substack/hyperspace |
| 07:38:34
| <jesusabdullah> | which to be fair is rarely |
| 07:39:50
| <Wraithan> | substack: looks like a pain in the ass to setup |
| 07:40:09
| <substack> | setup? |
| 07:40:19
| <substack> | there is no setup |
| 07:41:24
| * stagas | quit (Read error: Connection reset by peer) |
| 07:42:40
| <substack> | you just use it like this https://github.com/substack/markdown-directory#example |
| 07:42:51
| <substack> | you pipe streams into html elements |
| 07:43:22
| <Wraithan> | sorry I mispoke |
| 07:43:32
| <Wraithan> | looks like a pain in the ass to rewrite all my stuff to use that |
| 07:43:53
| <Wraithan> | and a ton of intellectual overhead |
| 07:44:13
| <Wraithan> | and with how young it is, flavor of the week as well |
| 07:44:53
| <Wraithan> | Hmm, actually history is longer than I expected |
| 07:45:07
| <Wraithan> | I guess I'll just rewrite everythign |
| 07:45:18
| <substack> | well you don't need to do that |
| 07:45:33
| <substack> | you could write a custom browserify transform |
| 07:45:36
| <substack> | for jade or whatever |
| 07:46:23
| <substack> | or just use brfs to fs.readFileSync() the jade files and jade.render() them |
| 07:48:11
| <Wraithan> | I would just do the brfs method, if jade didn't make browserify shit itself trying to include it |
| 07:48:23
| <Wraithan> | Error: module "./lib-cov/jade" not found from "/Users/cmcdonald/devel/coalesce/node_modules/jade/index.js" |
| 07:49:52
| <Wraithan> | I guess I can just use two templating setups until I get around to rewriting my jade stuff to all be hyperstream |
| 07:50:29
| <Wraithan> | trying to just power through writing a website using node so I can say I did it and point out the numerous things that have pissed me off, been broken as shit, etc |
| 08:01:19
| * dominictarr | quit (Quit: dominictarr) |
| 08:03:22
| * jcrugzz | quit (Ping timeout: 246 seconds) |
| 08:21:13
| * no9 | quit (Ping timeout: 246 seconds) |
| 08:29:56
| * dguttman | joined |
| 08:34:38
| * no9 | joined |
| 08:34:54
| * djcoin | joined |
| 08:37:42
| <jesusabdullah> | haha, sounds good Wraithan |
| 08:40:45
| * dominictarr | joined |
| 08:41:02
| * mikolalysenko | joined |
| 08:41:54
| * vitorpacheco | quit (Read error: Connection reset by peer) |
| 08:45:23
| * mikolalysenko | quit (Ping timeout: 240 seconds) |
| 08:46:24
| * dguttman | quit (Ping timeout: 240 seconds) |
| 09:03:45
| * ralphtheninja | joined |
| 09:12:08
| <dominictarr> | juliangruber hij1nx st_luke i'll be in berlin tomorrow! |
| 09:12:18
| <juliangruber> | dominictarr !!! |
| 09:12:25
| <juliangruber> | awesome |
| 09:12:39
| <juliangruber> | on what occasion? |
| 09:13:58
| <dominictarr> | just to come and hang out with you guys and hack on level-* |
| 09:17:29
| <substack> | groovy! |
| 09:18:24
| <substack> | dominictarr: haha I'm watching http://skillsmatter.com/podcast/open-source-dot-net/gary-short just for the absolute hell of it |
| 09:19:57
| <dominictarr> | back in a bit! |
| 09:20:03
| <juliangruber> | dominictarr: :) |
| 09:20:15
| <substack> | I must understand the appeal of these big stacks |
| 09:20:16
| * dominictarr | quit (Quit: dominictarr) |
| 09:22:12
| * emilisto_ | changed nick to emilisto |
| 09:22:35
| * timoxley | joined |
| 09:35:55
| * nicholasf | quit (Read error: Connection reset by peer) |
| 09:36:19
| * nicholasf | joined |
| 10:01:04
| * jibay | joined |
| 10:13:38
| * nicholasf | quit (Read error: Connection reset by peer) |
| 10:13:50
| * nicholasf | joined |
| 10:33:49
| * nicholasf | quit (Read error: Connection reset by peer) |
| 10:34:16
| * nicholasf | joined |
| 10:37:45
| * missinglink | joined |
| 10:50:45
| * thl0 | joined |
| 10:58:07
| * nicholasf | quit (Read error: Connection reset by peer) |
| 10:58:16
| * nicholasf | joined |
| 10:59:07
| * nicholasf | quit (Read error: Connection reset by peer) |
| 10:59:17
| * nicholasf | joined |
| 11:00:07
| * nicholasf | quit (Read error: Connection reset by peer) |
| 11:00:16
| * nicholasf | joined |
| 11:17:50
| * dominictarr | joined |
| 11:19:19
| <dominictarr> | substack: appeal of big stacks ~= much like authoritarianism, a strong leader decides everything for you, and you have no responsibility |
| 11:19:34
| <dominictarr> | basically, no one can blame you |
| 11:19:46
| <dominictarr> | when everything goes wrong |
| 11:30:08
| <jesusabdullah> | fuckin' right |
| 11:30:19
| <jesusabdullah> | why am I still awake I have to get up early |
| 11:32:16
| <jesusabdullah> | dominictarr: http://www.reddit.com/r/javascript/comments/1f7ru1/how_do_i_find_javascript_libraries/ca7yv1w?context=3 |
| 11:32:23
| <jesusabdullah> | dominictarr: (that's my alt account) |
| 11:33:03
| <dominictarr> | you are niggl ? |
| 11:33:18
| <dominictarr> | oh, no, you are jhizzle |
| 11:47:28
| * dools_ | quit (Read error: Connection reset by peer) |
| 11:47:48
| * dools | joined |
| 11:48:06
| * jesusabdullah | quit (Ping timeout: 264 seconds) |
| 11:48:42
| * owen1 | quit (Ping timeout: 264 seconds) |
| 11:48:46
| * jesusabdullah | joined |
| 11:50:09
| * owen1 | joined |
| 12:11:34
| <timoxley> | dominictarr substack is there anything we can do to lighten the weight of some of these modules https://gist.github.com/timoxley/5721056 |
| 12:11:57
| <timoxley> | most of that fat is in examples |
| 12:12:10
| <timoxley> | esprima/tests is >3M |
| 12:12:16
| <dominictarr> | you don't get all of that when you browserify, so who cares? |
| 12:12:40
| <dominictarr> | also, npm will cache it, so you arn't downloading that everytime you install, either |
| 12:13:41
| <timoxley> | dominictarr agreed, that works for most cases but some people don't have good internet |
| 12:13:48
| <thl0> | It's very surprising that some modules I end up writing aren't on npm yet |
| 12:13:51
| <thl0> | i.e. https://github.com/thlorenz/extend-url |
| 12:14:03
| <thl0> | someone must have needed this in the past ?? |
| 12:14:23
| <timoxley> | dominictarr … or they're putting their code on devices with limited storage |
| 12:14:43
| <timoxley> | isn't this what .npmignore is for? |
| 12:15:05
| <dominictarr> | timoxley: yes, but we don't maintain many of those modules |
| 12:15:27
| <dominictarr> | simplest would be to go through and delete tests and examples, and unused deps |
| 12:15:48
| <dominictarr> | you could even use module-deps to find the things that you shouldn't delete! |
| 12:16:06
| <timoxley> | dominictarr what do you mean " we don't maintain many of those modules" |
| 12:16:34
| * dguttman | joined |
| 12:17:51
| <dominictarr> | like esprima |
| 12:18:04
| <dominictarr> | so, we can't update the .npmignore |
| 12:18:14
| <dominictarr> | well you could do a pull request, i guess... |
| 12:18:40
| <dominictarr> | *click* oh, this is for ninja blocks, isn't it? |
| 12:19:08
| <dominictarr> | which is based on an rpi, correct? |
| 12:24:09
| <timoxley> | dominictarr rpi? |
| 12:24:14
| <timoxley> | oh |
| 12:24:20
| <timoxley> | no it's on a beaglebone |
| 12:24:57
| <timoxley> | dominictarr and yes that's the problem |
| 12:25:03
| <dominictarr> | right, same basic idea |
| 12:25:32
| <timoxley> | dominictarr the big files in there are mostly living in examples |
| 12:25:33
| <dominictarr> | it always helps to discuss applications in concrete first, then abstract after |
| 12:25:41
| <timoxley> | point taken |
| 12:26:21
| <dominictarr> | that way, you can better see the multitude of possible solutions, but anyway, back to the problem |
| 12:26:34
| <timoxley> | dominictarr e.g. 10M ./node_modules/reconnect/examples |
| 12:26:34
| <dominictarr> | how are you getting data onto them? |
| 12:26:51
| <dominictarr> | npm install on the device? or just once? |
| 12:27:03
| <dominictarr> | is it prewired? |
| 12:27:04
| <timoxley> | dominictarr tarball at the moment |
| 12:27:19
| <dominictarr> | right - so you set it once, and then leave it? |
| 12:27:40
| <timoxley> | dominictarr correct |
| 12:27:47
| <timoxley> | I could manually go delete that stuff |
| 12:27:55
| <timoxley> | but that sucks |
| 12:28:07
| <dominictarr> | you could write a script to do that, easy |
| 12:28:46
| <timoxley> | … I guess… but, the core of the problem is crap coming down in an npm install that isn't required for deployment |
| 12:29:01
| <timoxley> | e.g. examples, tests etc |
| 12:30:00
| <dominictarr> | sure. well, tests are worth having |
| 12:30:15
| <timoxley> | in production? |
| 12:30:37
| <dominictarr> | well, i wouldn't want to remove them from packages… for other reasons |
| 12:30:56
| <dominictarr> | regards to future possible trans-npm testing systems... |
| 12:31:24
| <dominictarr> | timoxley: also, npm installs more than it technically needs to |
| 12:31:56
| <gildean> | maybe npm could have a switch for this? --notestsandexamples |
| 12:32:22
| <gildean> | it does take a long time to install something bigger onto an rpi with a slower sd-card, for example |
| 12:32:30
| <dominictarr> | the strongest benefit of making a script, is that you do not have to convince anyone else to merge a change |
| 12:37:18
| <thl0> | timoxley: if esprima is too big, you could try acorn |
| 12:37:48
| <thl0> | its very similar, although the token format may be a bit different |
| 12:42:05
| <timoxley> | thl0 problem is esprima inside brwoserify inside a module's examples |
| 12:42:31
| <thl0> | timoxley: ah, that's ugly :( |
| 12:42:58
| <thl0> | I guess PR then like dominictarr said |
| 12:43:32
| <timoxley> | thl0 https://gist.github.com/timoxley/5721056#file-gistfile2-txt |
| 12:43:59
| <thl0> | timoxley: yep, that sucks |
| 12:46:44
| <dominictarr> | timoxley: [email protected] now ignores examples/* |
| 12:47:39
| <dominictarr> | the npm install stragety could be improved too |
| 12:47:48
| <dominictarr> | like, it could install deduped by default |
| 12:48:19
| <timoxley> | dominictarr thanks, agree |
| 12:48:41
| <dominictarr> | I've been playing with that, but it's low priority for me |
| 12:49:36
| <dominictarr> | but I came up with an approach that installs 30% less deps on average (sampled a few large projects, express, npm, browserify) |
| 12:50:06
| <dominictarr> | and I didn't actually install anything, just generated the tree, but it could work. |
| 12:50:44
| <dominictarr> | timoxley: looks like you could do npm dedupe too? |
| 12:51:03
| <dominictarr> | looks like two different versions of shoe? |
| 12:54:34
| <dominictarr> | timoxley: have also widened the acceptable ranges on some reconnect deps - should help you get the better deduping |
| 12:55:01
| <timoxley> | ./node_modules//reconnect/examples/shoe isn't installed via npm |
| 12:55:09
| <timoxley> | oh |
| 12:55:43
| <timoxley> | nvm, it's just exma[ple name |
| 12:58:04
| <dominictarr> | timoxley: try the latest reconnect |
| 12:59:48
| <timoxley> | dominictarr ok rad |
| 13:09:42
| * owenb__ | joined |
| 13:10:23
| * owenb_ | quit (Ping timeout: 264 seconds) |
| 13:10:23
| * dools | quit (Ping timeout: 264 seconds) |
| 13:10:26
| * emilisto | quit (Ping timeout: 264 seconds) |
| 13:10:27
| * jjjohnny | quit (Ping timeout: 264 seconds) |
| 13:10:34
| * dools_ | joined |
| 13:10:49
| * kanzure | quit (Ping timeout: 264 seconds) |
| 13:10:50
| * emilisto | joined |
| 13:11:23
| * kanzure | joined |
| 13:12:16
| * owenb__ | changed nick to owenb_ |
| 13:13:47
| * kevino80 | joined |
| 13:15:16
| * jjjohnny | joined |
| 13:15:41
| * chilts_ | joined |
| 13:17:05
| <thl0> | dominictarr: if I just need to create an outbound stream what module do I use? |
| 13:17:27
| <thl0> | i.e. I create it and write to it -- just writeable stream or is there something better? |
| 13:18:51
| * chilts | quit (Write error: Broken pipe) |
| 13:18:52
| * harrow | quit (Ping timeout: 325 seconds) |
| 13:19:40
| * harrow | joined |
| 13:20:31
| <thl0> | I guess Raynos write-stream will do the trick https://npmjs.org/package/write-stream |
| 13:20:40
| <juliangruber> | dominictarr: what's the motivation behind all those "broaden ranges" commits? |
| 13:20:51
| * no9 | quit (Ping timeout: 273 seconds) |
| 13:20:55
| <dominictarr> | make dedupe easier |
| 13:21:21
| <dominictarr> | I've only broardened ranges for authors that I trust to use semver properly |
| 13:21:48
| * no9 | joined |
| 13:23:02
| <dominictarr> | timoxley needed it, because he is trying to use reconnect etc, on a beagleboard, which has quite limited resources |
| 13:24:35
| <creationix> | dominictarr: yes, please use semver ranges where possible |
| 13:24:47
| <creationix> | you can always shrinkwrap production servers if you're worried about things changing |
| 13:28:52
| * thl0 | quit (Ping timeout: 246 seconds) |
| 13:51:33
| * fallsemo | joined |
| 13:52:08
| * Wraithan1 | joined |
| 13:52:19
| * Wraithan | quit (Ping timeout: 246 seconds) |
| 13:52:40
| * jibay | quit (Ping timeout: 246 seconds) |
| 13:53:07
| * jibay | joined |
| 14:08:06
| * thl0 | joined |
| 14:24:06
| * no9 | quit (Ping timeout: 245 seconds) |
| 14:27:01
| * mikolalysenko | joined |
| 14:28:05
| * st_luke | joined |
| 14:34:04
| * mikeal | quit (Quit: Leaving.) |
| 14:43:54
| * timoxley | quit (Ping timeout: 240 seconds) |
| 14:44:59
| * no9 | joined |
| 14:54:35
| * defunctzombie_zz | changed nick to defunctzombie |
| 14:58:44
| * st_luke | quit (Remote host closed the connection) |
| 15:01:56
| * jcrugzz | joined |
| 15:05:16
| * mikeal | joined |
| 15:08:45
| * sveisvei__ | quit (Quit: Connection closed for inactivity) |
| 15:12:10
| * mikeal | quit (Quit: Leaving.) |
| 15:26:19
| * jcrugzz | quit (Ping timeout: 264 seconds) |
| 15:30:51
| * jxson | joined |
| 15:31:32
| * jxson | quit (Remote host closed the connection) |
| 15:33:32
| * jxson_ | joined |
| 15:34:03
| <rook2pawn> | so im trying to do something like... var s = new Stream; .. http.createServer().on('connection',function(obj) { obj.pipe(s) }) .. how can i access the connection stream on the server? |
| 15:36:19
| * kevino80 | quit (Remote host closed the connection) |
| 15:40:43
| * jxson_ | quit (Ping timeout: 264 seconds) |
| 15:43:55
| * jxson | joined |
| 15:44:10
| * defunctzombie | changed nick to defunctzombie_zz |
| 15:46:15
| * thl0 | quit (Read error: Connection reset by peer) |
| 15:47:16
| * thl0 | joined |
| 15:49:17
| * thl0 | quit (Remote host closed the connection) |
| 15:57:42
| * kevino80 | joined |
| 16:00:27
| * nicholasf | quit (Read error: Connection reset by peer) |
| 16:00:28
| * tilgovi | joined |
| 16:00:56
| * nicholasf | joined |
| 16:02:09
| * djcoin | quit (Quit: WeeChat 0.4.0) |
| 16:15:20
| * defunctzombie_zz | changed nick to defunctzombie |
| 16:18:48
| * Wraithan1 | part ("WeeChat 0.4.1") |
| 16:21:31
| * no9 | quit (Ping timeout: 264 seconds) |
| 16:22:16
| * yorick | joined |
| 16:31:33
| * defunctzombie | changed nick to defunctzombie_zz |
| 16:34:00
| * no9 | joined |
| 16:35:08
| * jxson | quit (Remote host closed the connection) |
| 16:43:08
| <dominictarr> | rook2pawn: which connection stream? |
| 16:43:31
| * dominictarr | quit (Quit: dominictarr) |
| 16:43:57
| * defunctzombie_zz | changed nick to defunctzombie |
| 16:44:10
| * mikeal | joined |
| 16:44:16
| * fotoverite | joined |
| 16:45:19
| * tilgovi | quit (Remote host closed the connection) |
| 16:51:38
| * defunctzombie | changed nick to defunctzombie_zz |
| 16:53:53
| * owenb_ | quit (Ping timeout: 240 seconds) |
| 16:55:18
| * niftylettuce | quit (Ping timeout: 264 seconds) |
| 16:55:30
| * kevinohara80 | joined |
| 16:55:47
| <rook2pawn> | the connection stream from the server to the specific connecting client, where server http.createServer() and client is net.connect() |
| 16:56:09
| * tanepiper | quit (Ping timeout: 252 seconds) |
| 16:56:09
| <rook2pawn> | from the perspective of the server |
| 16:57:53
| * guybrush | quit (Quit: gnag!) |
| 16:58:03
| * guybrush | joined |
| 16:58:21
| * ryanseddon | quit (Ping timeout: 240 seconds) |
| 16:58:28
| * kevino80 | quit (Ping timeout: 261 seconds) |
| 17:00:24
| * missinglink | quit (Ping timeout: 240 seconds) |
| 17:10:24
| <mikolalysenko> | early results for specialization seem promisong |
| 17:10:24
| <mikolalysenko> | *promising |
| 17:10:46
| <mikolalysenko> | seems to be about 2x faster than bind() for small functions |
| 17:14:53
| <Raynos> | thl0: I wouldnt use that |
| 17:15:00
| <Raynos> | thl0: I would use stream.Writable |
| 17:15:09
| <Raynos> | thl0: or through |
| 17:15:43
| * jxson | joined |
| 17:16:07
| * dguttman | quit (Read error: Connection reset by peer) |
| 17:16:58
| <Raynos> | defunctzombie_zz: ping |
| 17:19:10
| * LOUDBOT | quit (Read error: Connection reset by peer) |
| 17:22:41
| * no9 | quit (Ping timeout: 248 seconds) |
| 17:35:45
| * no9 | joined |
| 17:38:13
| * ELLIOTTCABLE | joined |
| 17:39:02
| * ellio | quit (Read error: Operation timed out) |
| 17:39:02
| * gozala_ | quit (Read error: Operation timed out) |
| 17:39:22
| * ellio | joined |
| 17:39:23
| * gozala_ | joined |
| 17:45:45
| * thl0 | joined |
| 17:58:25
| * AvianFlu | joined |
| 18:01:17
| * nicholasf | quit (Read error: Connection reset by peer) |
| 18:01:25
| * nicholasf | joined |
| 18:07:14
| * jcrugzz | joined |
| 18:26:26
| * tanepiper | joined |
| 18:27:17
| * mikeal | quit (Quit: Leaving.) |
| 18:29:50
| <mikolalysenko> | Hmm results were not as good as I initially though |
| 18:29:52
| <mikolalysenko> | *t |
| 18:30:07
| <mikolalysenko> | here are numbers for function specialization: |
| 18:30:12
| <mikolalysenko> | Time for manual inline --- 2668 |
| 18:30:12
| <mikolalysenko> | Time for bind() --- 2706 |
| 18:30:12
| <mikolalysenko> | Time for closure --- 2828 |
| 18:30:13
| <mikolalysenko> | Time for specialize() --- 2621 |
| 18:30:30
| <mikolalysenko> | this is on a simple cellular automata benchmark |
| 18:30:47
| <mikolalysenko> | so specializing is a lot of work for a pretty small speed up... |
| 18:31:50
| <mikolalysenko> | not sure why it is faster than manual inline, probably because I used a closure to define the manual inline while I called Function() to construct the specialized routine |
| 18:32:35
| <mikolalysenko> | here is the code btw: https://github.com/mikolalysenko/specialize/blob/master/benchmark/ca.js#L7 |
| 18:32:59
| <mikolalysenko> | the bottom line is v8's bind() does surprisingly well on that simple example |
| 18:33:53
| * dguttman | joined |
| 18:52:03
| <mikolalysenko> | bah. performance advantage disappears if you hammer on the bound version enough |
| 18:52:14
| <mikolalysenko> | so that was a waste of a day |
| 18:52:26
| * owenb__ | joined |
| 18:53:12
| <mikolalysenko> | so, manually specializing code in JS doesn't work so great :P |
| 18:54:59
| <jesusabdullah> | bummer |
| 18:55:50
| * ryanseddon | joined |
| 18:56:17
| <jesusabdullah> | https://github.com/joyent/node/issues/5636 Gotta love node issues |
| 18:57:41
| * mikeal | joined |
| 18:58:54
| * niftylettuce | joined |
| 19:07:07
| * mikeal | quit (Ping timeout: 260 seconds) |
| 19:08:52
| * thl0_ | joined |
| 19:09:21
| * thl0 | quit (Ping timeout: 248 seconds) |
| 19:11:26
| * kevinohara80 | quit (Remote host closed the connection) |
| 19:17:16
| * stagas | joined |
| 19:18:54
| <guybrush> | lol jesusabdullah |
| 19:21:10
| <jesusabdullah> | fuck I don't wanna go apartment hunting |
| 19:25:25
| * kevino80 | joined |
| 19:47:32
| <jesusabdullah> | juliangruber: You're using your pullover fork for stuff? |
| 19:47:47
| <juliangruber> | jesusabdullah yes i am |
| 19:47:51
| <jesusabdullah> | neat |
| 19:48:00
| <jesusabdullah> | and it's workin' relatively well I take it? |
| 19:48:12
| <jesusabdullah> | I have to admit I haven't, umm, put it through the paces myself |
| 19:48:19
| <jesusabdullah> | the project I had in mind for it went on hiatus |
| 19:48:29
| <jesusabdullah> | though I might brush it off sometime in the next week or so |
| 19:48:43
| * tilgovi | joined |
| 19:48:51
| <jesusabdullah> | I'll take care of this PR today, probably after lunch |
| 19:50:55
| <juliangruber> | jesusabdullah: it's totally working for what i want it to do :) |
| 19:51:00
| <jesusabdullah> | fantastic :D |
| 19:51:04
| <juliangruber> | will be used in another module, will ping you when it's done |
| 19:51:37
| <jesusabdullah> | nice |
| 19:51:46
| <jesusabdullah> | uhhhh what to do for breakfast today |
| 19:51:59
| <jesusabdullah> | >_< |
| 19:57:17
| * tilgovi | quit (Remote host closed the connection) |
| 19:58:11
| * mikeal | joined |
| 20:02:40
| * mikolalysenko | quit (Ping timeout: 250 seconds) |
| 20:03:04
| * mikeal | quit (Ping timeout: 276 seconds) |
| 20:04:10
| <jesusabdullah> | chapel: Rumor has it your referral bonus is pretty much squared away (unless I run off with some other floozy of a company) |
| 20:09:26
| * mikolalysenko | joined |
| 20:13:39
| <mikolalysenko> | well. this absolutely did not work: https://github.com/mikolalysenko/specialize |
| 20:14:32
| <mikolalysenko> | but a lesson was learned: bind works pretty well for inlining functions - providing they are simple enough and don't touch global scope |
| 20:14:43
| <jez0990> | mikolalysenko: I'm sorry to hear that! Really interesting stuff though |
| 20:15:04
| <jez0990> | I just watched your 2008 talk on fibers in Tango - also very interesting! |
| 20:15:12
| <mikolalysenko> | jez0990: oh that was so long ago! |
| 20:15:29
| <mikolalysenko> | jez0990: I haven't done anything with D in forever |
| 20:15:57
| <mikolalysenko> | I think that the fibers code I wrote really long ago is still in the standard library though |
| 20:16:51
| <jez0990> | mikolalysenko: time flies :) ...how do you see those sorts of concepts fitting into your current view on js? |
| 20:18:12
| <mikolalysenko> | jez0990: well, harmony is going to get yield which is nice. I think that having coroutines does simplify a lot of things |
| 20:18:29
| <mikolalysenko> | but lately I find myself not worrying as much about that sort of stuff and focusing more on algorithms and data structures |
| 20:19:07
| <mikolalysenko> | I think the bigger issues are really memory management in javascript |
| 20:19:30
| <mikolalysenko> | I also still try to avoid writing state machines if possible since they are basically an obfuscated goto |
| 20:23:29
| <jez0990> | mmm I suppose that kind of thinking is predominantly irrelevant in writing small reusable modules |
| 20:24:41
| <mikolalysenko> | well coroutines are useful anywhere you have state |
| 20:24:53
| <mikolalysenko> | basically they let you apply structured programming techniques to concurrency |
| 20:25:06
| <mikolalysenko> | without that you have to resort to state machines (ie goto/jump logic) |
| 20:25:14
| * chilts_ | changed nick to chilts |
| 20:25:27
| <mikolalysenko> | in a state machine you represent your state explicitly, kind of like writing labels for code points |
| 20:25:48
| <mikolalysenko> | while in a coroutine your state is represented implicitly by whatever loop or function block you are in |
| 20:26:33
| <mikolalysenko> | so it does simplify things, but you can still program with gotos/state machines just as well |
| 20:27:10
| <mikolalysenko> | what I've always found fascinating though is that the idea of a coroutine was discovered *before* the idea of a function |
| 20:28:33
| <mikolalysenko> | it is funny that before programs even had things like stacks and subroutines people were using coroutines to manage control flow |
| 20:28:56
| <jez0990> | mikolalysenko: I'll definitely need to have a play to really appreciate this |
| 20:29:43
| <mikolalysenko> | jez0990: yeah, if they get added to the next javascript it will definitely be a good thing on the whole I think |
| 20:30:05
| <jez0990> | in your talk you said stacks existed only so you could run an OS, right? |
| 20:30:14
| <mikolalysenko> | no they are basically an optimization |
| 20:30:26
| <mikolalysenko> | stacks were created because in the old days memory management was hard |
| 20:30:37
| <mikolalysenko> | the first programs statically blocked out memory |
| 20:31:03
| <mikolalysenko> | then people came up with lists for allocating memory |
| 20:31:07
| <mikolalysenko> | then came stacks |
| 20:31:13
| <mikolalysenko> | stacks are an optimzation basically |
| 20:31:35
| <mikolalysenko> | because they keep memory compact and don't require much maintenance |
| 20:31:47
| <mikolalysenko> | in theory if your gc was super awesome you wouldn't need it |
| 20:32:02
| <mikolalysenko> | but in practice stacks let you allocate and control the lifetime of memory efficiently |
| 20:32:47
| <mikolalysenko> | stacks were also necessary to create recursive subroutine calls |
| 20:33:18
| <mikolalysenko> | basically in a subroutine you can free all its memory once it returns |
| 20:33:43
| <mikolalysenko> | but in a coroutine (or even a closure) you need to keep its local variables around |
| 20:33:56
| <mikolalysenko> | so it requires having a garbage collector to make it work typically |
| 20:34:15
| <mikolalysenko> | (or else you have to manually manage its lifetime) |
| 20:34:56
| <mikolalysenko> | but semantically speaking you could replace a stack with your garbage collector and other than the performance hit you wouldn't be able to tell the difference |
| 20:35:00
| <jez0990> | mikolalysenko: thanks for the explanations |
| 20:35:31
| <jez0990> | I love coming here to learn, oh University of Stackvm.... |
| 20:36:57
| <jez0990> | I really should've paid more attention and read the background during my degree, and learned this when I had the chance |
| 20:38:17
| <mikolalysenko> | jez0990: well never too late to start |
| 20:38:30
| <mikolalysenko> | or even go back and brush up on things |
| 20:38:48
| <mikolalysenko> | it is often much easier second time around you can sometimes find things you missed |
| 20:39:37
| <mikolalysenko> | actually, going back to coroutines it is my hope that harmony's yield will eventually kill off all the promise/async libraries out there |
| 20:39:45
| <mikolalysenko> | since they will basically become superfluous |
| 20:40:28
| <mikolalysenko> | so it will probably stabilize the js library world quite a bit |
| 20:40:44
| <mikolalysenko> | though that could take a long time for all the browsers to catch up |
| 20:50:27
| * thl0_ | quit (Remote host closed the connection) |
| 20:52:28
| * joliss | joined |
| 20:54:39
| * shama | joined |
| 20:54:46
| <jez0990> | mikolalysenko: that is the dream! (regarding brushing up) |
| 20:54:53
| <jez0990> | also it seems Domenic_ did a good presentation on this http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript ...a shame I can't find a recording! |
| 20:58:48
| * mikeal | joined |
| 21:03:31
| * mikeal | quit (Ping timeout: 276 seconds) |
| 21:05:25
| * nexxy | changed nick to xyxne |
| 21:08:42
| * jcrugzz_ | joined |
| 21:11:19
| * jcrugzz | quit (Ping timeout: 264 seconds) |
| 21:12:49
| * ins0mnia | joined |
| 21:13:17
| <ins0mnia> | ralphtheninja: ping!!!! |
| 21:13:38
| * thl0 | joined |
| 21:16:33
| <ins0mnia> | we need a stackvm logo!!! |
| 21:16:59
| <ins0mnia> | ralphtheninja: Just arrived Tyresö!! |
| 21:17:21
| <jez0990> | ins0mnia: http://stackvm.com/stackvm.png |
| 21:17:31
| <ins0mnia> | yay!!!!! |
| 21:18:21
| <jez0990> | I think an Anarchy symbol with a hexagon instead of a circle would be kinda cool |
| 21:18:28
| <ins0mnia> | All I need now is to print it on a flag (need a high res one) |
| 21:18:33
| <ins0mnia> | And plant it infront of the house!! |
| 21:18:38
| <jez0990> | maybe for anarchyos |
| 21:18:39
| <jez0990> | lol |
| 21:18:50
| * AvianFlu | quit (Remote host closed the connection) |
| 21:19:25
| <ins0mnia> | stackvm conquers Sweden |
| 21:20:55
| * kevino80 | quit (Remote host closed the connection) |
| 21:22:34
| <jez0990> | next up: the Internet |
| 21:22:37
| <substack> | yield is weird |
| 21:22:50
| <substack> | I don't see how it's better than just regular callbacks |
| 21:22:58
| * mikeal | joined |
| 21:23:05
| <substack> | it just forces weirdness downstream |
| 21:30:19
| * kevino80 | joined |
| 21:30:24
| * ins0mnia | quit (Ping timeout: 260 seconds) |
| 21:35:19
| * jcrugzz_ | changed nick to jcrugzz |
| 21:37:05
| * defunctzombie_zz | changed nick to defunctzombie |
| 21:38:27
| <defunctzombie> | Raynos: pong |
| 21:38:40
| <Raynos> | defunctzombie: generators without yield |
| 21:38:42
| <Raynos> | explain them |
| 21:38:54
| <Raynos> | I started doing https://github.com/Raynos/continuable-generators |
| 21:39:01
| <defunctzombie> | generators without yield at the "user" level |
| 21:39:11
| * defunctzombie | thinks it might require co-routines tho |
| 21:39:34
| <defunctzombie> | Raynos: gets back to that gist I wrote a while ago |
| 21:39:57
| <Raynos> | because right now I quite like yield |
| 21:40:05
| * kevino80 | quit (Remote host closed the connection) |
| 21:40:07
| <Raynos> | it basically says var res = yield thunk |
| 21:40:09
| <Raynos> | which is like monads |
| 21:40:13
| <Raynos> | var res <- thunk |
| 21:40:18
| <defunctzombie> | https://gist.github.com/shtylman/5267456 |
| 21:40:19
| <Raynos> | do notation ! |
| 21:40:35
| * mikeal | quit (Quit: Leaving.) |
| 21:41:06
| <Raynos> | defunctzombie: your yield / resume thing is crazy |
| 21:41:11
| <Raynos> | I understand it but its crazy |
| 21:41:15
| <Raynos> | i'd rather have yield syntax |
| 21:42:25
| <defunctzombie> | heh |
| 21:42:41
| <defunctzombie> | i'd rather not cause I just want to write what I mean |
| 21:42:51
| <defunctzombie> | and not thing about the "concurrency" implications |
| 21:42:59
| <defunctzombie> | I just want to read a file, do stuff, etf |
| 21:43:07
| <defunctzombie> | using regular looking code |
| 21:43:18
| <defunctzombie> | and then if I need anything fancier then use something special |
| 21:43:25
| <defunctzombie> | the fancy case is not the common case |
| 21:43:27
| * shama_ | joined |
| 21:44:22
| <mikolalysenko> | the way I look at it is that yield is all about applying structured programming to concurrent stuff |
| 21:44:53
| <defunctzombie> | Raynos: but I think for the thing I described you need co-routines |
| 21:45:38
| <Raynos> | I guess |
| 21:45:45
| <mikolalysenko> | the only real problem with yield is that it creates lots of garbage on your heap, but then closures do the same thing |
| 21:46:09
| <mikolalysenko> | at least compared to the current state of affairs in js it seems that there is no downside |
| 21:46:25
| * shama | quit (Ping timeout: 276 seconds) |
| 21:47:19
| <mikolalysenko> | in fact a well implemented yield might result in less garbage overall than allocating a bunch of closures at each point where you want to yield |
| 21:47:25
| <substack> | yield is gross |
| 21:47:26
| <substack> | will not use |
| 21:47:36
| <mikolalysenko> | also yield has the advantage that it is easy to put in things like loops |
| 21:47:47
| <mikolalysenko> | or if blocks |
| 21:47:49
| <defunctzombie> | Raynos: actually, maybe I can do it without co-ros |
| 21:47:56
| <defunctzombie> | substack: I agree |
| 21:48:12
| <mikolalysenko> | I don't really see why yield is gross... |
| 21:48:24
| <substack> | the api is WEIRD |
| 21:48:39
| <substack> | you do your function a special way with a * in the signature |
| 21:48:44
| <substack> | and then you call yield inside it |
| 21:48:48
| <mikolalysenko> | because they need to be allocated |
| 21:48:55
| <substack> | which turns the function result into a special magical kind of thing |
| 21:48:58
| <substack> | that you call .next() on |
| 21:49:04
| <substack> | how is that not really fucking weird and magical and surprising |
| 21:49:09
| <substack> | there is so much surface area there |
| 21:49:14
| <mikolalysenko> | it doesn't seem that weird to me |
| 21:49:30
| <mikolalysenko> | the first time you call a coroutine you need to instantiate it |
| 21:49:35
| <substack> | I don't want there to be special kinds of functions that work completely differently from regular functions |
| 21:50:07
| <substack> | new/() is bad enough |
| 21:50:26
| <mikolalysenko> | in the case of coroutines though it seems necessary |
| 21:50:54
| <mikolalysenko> | the general usage is: 1. define coroutine 2. instantiate a coroutine 3. execute it |
| 21:50:57
| <substack> | necessary for what? |
| 21:51:02
| <substack> | you can already do callbacks |
| 21:51:14
| <guybrush> | it is amazing how much possibilities there are to do the same thing in js |
| 21:51:16
| <mikolalysenko> | you can |
| 21:51:20
| <substack> | which don't require any new semantics since the language is already built around that idea |
| 21:51:32
| <mikolalysenko> | you can also do stuff with switch statements and gotos |
| 21:51:37
| <guybrush> | i really do js for a long time now, then i read yield and im like "wtf is this even js?" |
| 21:51:38
| <substack> | everything is so flexible and consistent when you just use callbacks |
| 21:51:53
| <mikolalysenko> | you can do anything in a turing complete language |
| 21:51:56
| <substack> | I don't ever do switch statements or gotos |
| 21:52:00
| <substack> | in the first place |
| 21:52:04
| <mikolalysenko> | you could also do it all usin ski combinators or regexps |
| 21:52:21
| <mikolalysenko> | or a while loop with some if statements |
| 21:53:21
| <mikolalysenko> | structured programming constructs are not a necessity, but they do make some things "simpler" |
| 21:53:34
| <guybrush> | i will just use a lua vm in the js vm |
| 21:53:57
| <mikolalysenko> | if you like using loops better than using labels and jumps, then you might also like using yield better than cps or state machines |
| 21:54:04
| <mikolalysenko> | for example you can yield in a loop |
| 21:54:13
| <mikolalysenko> | doing this with closures is annoying (but possible) |
| 21:55:07
| * joliss | quit (Quit: joliss) |
| 21:56:20
| <mikolalysenko> | you can also use yield for lots of non-concurrency stuff too, like simpler iterators for data structures |
| 21:56:56
| <mikolalysenko> | for example you can do stuff like inorder traversal of ranges of trees really easily with coroutines |
| 21:57:05
| <mikolalysenko> | and it is a bit of a pita to do with visitor style iteration |
| 21:57:22
| <mikolalysenko> | and even more ugly with iterators |
| 21:57:41
| <Domenic_> | mikolalysenko: +1 to everything you say |
| 21:57:52
| * tilgovi | joined |
| 21:58:15
| <Domenic_> | the turing tarpit is not a pleasant place to be |
| 21:58:27
| <Domenic_> | this stuff is like the subject of my jsconf talk, excited for the recording |
| 21:58:42
| * joliss | joined |
| 22:00:37
| <mikolalysenko> | Domenic_: cool, do you have a link? |
| 22:00:55
| <mikolalysenko> | (for a video I mean, I saw the slide deck jez0990 posted earlier) |
| 22:01:57
| <Domenic_> | mikolalysenko: jsconf videos aren't released yet sadly |
| 22:02:09
| <Domenic_> | the slide deck was never recorded |
| 22:02:17
| <Domenic_> | a few other promise talks were but jsconf is my favorite |
| 22:02:59
| <substack> | I don't see how any of these new-fangled abstractions solve any of my problems. |
| 22:03:08
| <substack> | I don't seem to have the problems that they are attempting to solve. |
| 22:03:40
| <mikolalysenko> | substack: here is a simple example: a streaming parser |
| 22:04:12
| <mikolalysenko> | using yield you can actually use recursion and loops when you are parsing it out and yield exactly when the stream underruns |
| 22:05:31
| <mikolalysenko> | another example: streaming writer with proper backpressure |
| 22:05:35
| <substack> | you can already do that with functions |
| 22:05:38
| <mikolalysenko> | you can |
| 22:05:47
| <Domenic_> | you can also do it with gotos! |
| 22:05:48
| <substack> | modules already do backpressure correctly so you don't have to care |
| 22:05:50
| <substack> | you don't need it! |
| 22:05:57
| <Domenic_> | assembly is good too!!! |
| 22:06:03
| <mikolalysenko> | right, but yield makes it easier to write those modules |
| 22:06:15
| <substack> | how? |
| 22:06:24
| <mikolalysenko> | for example, suppose I have to write an array |
| 22:06:36
| <mikolalysenko> | I can loop over the elements of the array and yield if I have back pressure |
| 22:06:57
| <mikolalysenko> | it just looks like for(var i=0; i<100; ++i) { if(blocked) { yield } write(item[i]) } |
| 22:07:10
| <substack> | so that's not exactly a fair comparison in the first place |
| 22:07:22
| * thl0 | quit (Remote host closed the connection) |
| 22:07:28
| <substack> | you're comparing the absense of a feature with a full-fledged feature, not 2 fully-fledged approaches |
| 22:07:45
| <mikolalysenko> | not sure what you mean here... |
| 22:07:49
| <substack> | so of course using yield is going to seem simpler if you compare it to nothing |
| 22:07:56
| <substack> | compare yield to using native abstractions |
| 22:08:08
| <mikolalysenko> | sure, what would you recommend instead of using yield? |
| 22:08:17
| <substack> | through |
| 22:08:26
| <mikolalysenko> | I don't see how through fixes this problem... |
| 22:08:37
| * gozala_ | quit |
| 22:08:46
| * gozala_ | joined |
| 22:08:52
| * gozala_ | changed nick to gozala |
| 22:09:14
| <substack> | list(i,100).pipe(through(function (i) { this.queue(item[i]) })) |
| 22:09:24
| <substack> | for some list object stream function list() |
| 22:10:10
| <mikolalysenko> | what if you need to do something more complicated in the body? |
| 22:10:19
| <mikolalysenko> | like write multiple items conditionally? |
| 22:10:24
| <substack> | for example? |
| 22:10:31
| <mikolalysenko> | for example some of the items are larger than others, like jagged list |
| 22:10:34
| <substack> | what kind of condition? |
| 22:11:12
| <substack> | I don't see how it would be any different |
| 22:11:21
| <mikolalysenko> | for(var i=0; i<list.length; ++i) { if(blocked) { yield } write(list[i].length); for(var j=0; j<list[i].length; ++j) { if(blocked) { yield } write(list[i][j]); } } |
| 22:11:29
| <mikolalysenko> | basically a nested list |
| 22:11:31
| <substack> | oh, just sub-elements? |
| 22:11:35
| <substack> | I do that all the time |
| 22:11:38
| <mikolalysenko> | yeah each is variable size |
| 22:11:44
| <substack> | that's how gutter and hyperstream work |
| 22:11:54
| <substack> | you just pause the parent and resume it when the child is done |
| 22:11:56
| <substack> | it's pretty easy |
| 22:12:07
| <mikolalysenko> | it sounds a bit complicated, why don't you write it out? |
| 22:12:18
| * shama_ | quit |
| 22:12:25
| <substack> | because usually you would use a lib for this kind of thing, not write it in-place |
| 22:12:28
| * shama | joined |
| 22:12:28
| <substack> | but it would be something like |
| 22:14:30
| <substack> | list(0,100).pipe(through(function (i) { this.queue(list[i].length); this.pause(); list(0,list[i].length).pipe(through(function (j) { this.queue(list[i][j]) }, function () { this.resume() }.bind(this)) }) |
| 22:15:29
| <mikolalysenko> | first point: that code requires an extra malloc per each item in the first list |
| 22:15:32
| <substack> | although actually you would need 2 streams since the consumer might resume you |
| 22:15:41
| <mikolalysenko> | yeah that was point 2 |
| 22:15:46
| <substack> | but you can just .pipe(through()) at the end to fix that |
| 22:15:57
| <substack> | extra malloc? who cares |
| 22:16:06
| <mikolalysenko> | if the list is really big it would matter |
| 22:16:26
| <mikolalysenko> | look, I am not arguing that you can do it this way |
| 22:16:34
| <substack> | you could use more efficient abstractions if you want |
| 22:16:37
| <mikolalysenko> | but making a library for each possible control flow situation is a little crazy |
| 22:16:41
| <substack> | I'm just mentioning things that already exist |
| 22:16:51
| <mikolalysenko> | why not just make the language more expressive so it is easy to write this stuff and be done with it? |
| 22:16:59
| <substack> | because it's not easy! |
| 22:17:01
| <substack> | it's just as hard |
| 22:17:09
| <chrisdickinson> | expressiveness comes with its own cost |
| 22:17:12
| <mikolalysenko> | I think the stuff I wrote using yield was pretty easy |
| 22:17:14
| <substack> | only instead of using what the language already gives you, it complicates the language |
| 22:17:18
| <substack> | making everything even harder |
| 22:17:31
| <mikolalysenko> | not sure I understand that point |
| 22:17:54
| <substack> | consider what it's like to keep an entire language in your head |
| 22:17:59
| <substack> | not to mention learning a language |
| 22:18:06
| <substack> | not to mention reasoning about languages |
| 22:18:22
| <substack> | for an example of how bad all these special-cases can get, consider ruby |
| 22:18:24
| <substack> | there are 7 different kinds of functions |
| 22:18:54
| <substack> | defs, lambdas, block lambdas, generator functions, procs |
| 22:19:05
| <mikolalysenko> | yeah but that is stupid |
| 22:19:07
| <substack> | more I can't even remember |
| 22:19:09
| <mikolalysenko> | and it isn't how coroutines work |
| 22:19:23
| <mikolalysenko> | just saying that is dumb because ruby is dumb is a strawman argument |
| 22:19:34
| <substack> | generators clutter javascript functions in exactly the same way |
| 22:19:38
| <substack> | is why I mention it |
| 22:19:42
| <substack> | we don't need more special cases |
| 22:19:47
| <chrisdickinson> | along with => functions. |
| 22:19:57
| <substack> | yes! |
| 22:19:58
| <chrisdickinson> | (which introduce their own special case) |
| 22:20:01
| <substack> | special cases are bad |
| 22:20:02
| <mikolalysenko> | => are just functions with a fancy syntax for defining them |
| 22:20:07
| <substack> | mikolalysenko: it's not! |
| 22:20:11
| <substack> | it has unique semantics! |
| 22:20:41
| <mikolalysenko> | anyway it isn't even relevant to discussing coroutines. I think there is some value to the abstraction |
| 22:21:21
| <mikolalysenko> | and it isn't necessarily a bad idea to add a few extra features to the language. if you want something with minimal moving parts you can always just switch back to lisp |
| 22:21:59
| <substack> | it's so bad to do this |
| 22:22:10
| <substack> | after a certain point, languages should just be static |
| 22:22:30
| <substack> | and finished |
| 22:22:36
| <mikolalysenko> | yeah I'd agree with this point |
| 22:23:00
| <substack> | this new stuff just adds more complications for very marginal benefits completely destroyed by the added complexity cost |
| 22:23:01
| <mikolalysenko> | but I do think there is value in having coroutines around. if they put them, I'll use them. if harmony dies, I'll also be fine |
| 22:23:13
| <substack> | I hope harmony dies. |
| 22:23:22
| <substack> | it's just a grab bag like any other |
| 22:23:29
| <mikolalysenko> | well, binary data types are a pretty good idea |
| 22:23:39
| <substack> | a waterfall-esque drop of a bunch of features that only language nerds want |
| 22:23:50
| <substack> | and everybody else has to sort it all out |
| 22:23:50
| <mikolalysenko> | and they don't really change the language much. you could probably add them in as an html 5 extension |
| 22:24:15
| <mikolalysenko> | kind of like how they did typedarrays |
| 22:24:23
| <substack> | evolving APIs is really necessary |
| 22:24:25
| <substack> | evolving syntax isn't |
| 22:25:04
| <chrisdickinson> | one of my favorite things about JS is that it is such a small language with (relatively few) corner cases in parsing |
| 22:25:14
| <substack> | yes! |
| 22:25:20
| <mikolalysenko> | chrisdickinson: it still has quite a few though |
| 22:25:22
| <substack> | we have a lot of parsers because of this |
| 22:25:37
| <substack> | it's great |
| 22:25:46
| <chrisdickinson> | and a lot of good tooling because of having a lot of parsers |
| 22:26:03
| <substack> | syntax is not to place to be experimenting with concurrency abstractions |
| 22:26:03
| <substack> | we have plenty of syntax already |
| 22:26:10
| <chrisdickinson> | mikolalysenko: ASI and lookahead for regexen are the only ones that come to mind |
| 22:26:18
| <mikolalysenko> | what about labels? |
| 22:26:26
| <chrisdickinson> | that's fairly regular |
| 22:26:54
| <mikolalysenko> | anyway, I would tend to agree that adding more stuff = bad |
| 22:27:07
| <mikolalysenko> | but there are things that you can do with coroutines that you just can't implement as a library |
| 22:27:19
| <mikolalysenko> | and for that reason a strong case could be made for adding them to the language |
| 22:27:48
| <chrisdickinson> | (there's no special case for keys in objects as of es5, or for getters/setters in object literals, or single-expression => functions, or template literals, or yield, yield*, function*, and friends) |
| 22:27:49
| <mikolalysenko> | for =>, destructuring assignment, modules, etc. the argument is much less strong |
| 22:28:05
| <Domenic_> | i think static languages will lose to ones that grow in response to evolutions in our field |
| 22:28:18
| <mikolalysenko> | well, what about C? |
| 22:28:20
| <chrisdickinson> | i'm not 100% against generators, i'm against adding all of these language features in a single major version |
| 22:28:43
| <mikolalysenko> | chrisdickinson: agreed. I think harmony is a mixed bag with some good bad and ugly parts |
| 22:28:49
| <mikolalysenko> | like the modules in es5 are awful |
| 22:28:49
| <Domenic_> | I think if JS doesn't grow it will be in danger of dying. There were moments of real existential threat against Flash, WPF/Everywhere, and even today Dart is trying |
| 22:29:15
| <mikolalysenko> | I actually think asm.js is the biggest threat against js as we know it |
| 22:29:26
| <mikolalysenko> | I hope dart tanks (and it probably will) |
| 22:29:27
| <Domenic_> | chrisdickinson: when they stamp a version number on isn't that big a deal. features are implemented incrementally just like in every other piece of software |
| 22:29:30
| <substack> | Domenic_: C will never die |
| 22:29:39
| <substack> | that's a good thing |
| 22:29:46
| <chrisdickinson> | Domenic_: yes, but they're "available" as a big chunk, all at once, to the majority of developers |
| 22:29:49
| <mikolalysenko> | there's also fortran |
| 22:29:51
| <substack> | it also has barely changed |
| 22:30:08
| <Domenic_> | chrisdickinson: that's not really true. ie11 will have some es6 features, firefox already has some, chrome has some but they hide them behind a flag... |
| 22:30:17
| <Domenic_> | es6 features are delivered very gradually |
| 22:30:18
| <substack> | JS doesn't have to "win" |
| 22:30:22
| <substack> | it just has to be good at what it does |
| 22:30:33
| * defunctzombie | changed nick to defunctzombie_zz |
| 22:30:37
| <substack> | let whatever happens happen |
| 22:30:44
| <Domenic_> | i think it would be a shame if the JS ecosystem lost out to a proprietary one like Flash or Dart. |
| 22:31:05
| <substack> | "lost out" |
| 22:31:12
| <substack> | have you even looked at dart? |
| 22:31:14
| <substack> | it's so shitty |
| 22:31:22
| <mikolalysenko> | it is, but google is pushing it super hard |
| 22:31:32
| <substack> | they also push GWT |
| 22:31:36
| <substack> | they push GWT and dart at the same time |
| 22:31:38
| <substack> | nobody uses it |
| 22:31:40
| <substack> | nobody cares |
| 22:31:43
| <substack> | because it's garbage |
| 22:31:46
| <Domenic_> | substack: I think you have a different sense of asthetics than govern what drives adoption and use of languages in the large by the majority of programmers |
| 22:31:56
| <substack> | it solves google's problems and nobody else's |
| 22:32:02
| <Domenic_> | Java is successful, there is no doubt, but I bet everyone here thinks it's kind of shit |
| 22:32:23
| <substack> | if people want java they should just use java |
| 22:32:28
| <chrisdickinson> | it's "good enough" for the sweet spot it hits |
| 22:32:29
| <substack> | if people want dart they should just use that |
| 22:32:30
| <Domenic_> | But if Java and C were the only languages available for programming the browser, Java would win |
| 22:32:40
| <substack> | dart is even open source and all that noise |
| 22:32:52
| <substack> | I don't see why javascript needs to become dart |
| 22:32:58
| <substack> | we can just have separate languages |
| 22:33:06
| <substack> | that have their own specializations |
| 22:33:11
| <Domenic_> | Yes indeed |
| 22:33:18
| <Domenic_> | JavaScript and Dart are fundamentally different and will remain so |
| 22:33:42
| <Domenic_> | But improvements can be made to JavaScript that take advantage of what we've learned over the last 10 years while still preserving the spirit of JS |
| 22:33:43
| <substack> | Domenic_: so the other thing is |
| 22:34:04
| <Domenic_> | Even C and C++ evolve |
| 22:35:02
| <substack> | < Domenic_> I think if JS doesn't grow it will be in danger of dying. |
| 22:35:02
| <substack> | I think that's a very bold assertion. |
| 22:35:02
| <Domenic_> | C99 and C11 are definite shifts |
| 22:35:02
| <substack> | you kind of have the burden of proof to show that |
| 22:35:02
| <Domenic_> | I think it has been pretty close to proven |
| 22:35:02
| <Domenic_> | Flash, WPF/E |
| 22:35:02
| <Domenic_> | Even VBScript for a while |
| 22:35:02
| <substack> | C99 and C11 didn't matter at all to C adoption and usage |
| 22:35:02
| <substack> | people use C for what C is good at |
| 22:35:02
| <substack> | low-level bindings, kernels |
| 22:35:08
| <Domenic_> | These closed proprietary ecosystems got serious usage and uptake in developer communities and were destroying JS's prevalence on the web |
| 22:35:12
| <substack> | performance-critical algorithms |
| 22:35:33
| <Domenic_> | It was only the V8 performance revolution, and the WHATWG's breaking off from XHTML2 work to work on HTML5, Canvas, etc., that saved us. |
| 22:35:42
| <substack> | Domenic_: but then html APIs got good |
| 22:35:46
| <substack> | and JS got fast |
| 22:35:54
| <substack> | neither of which required syntax interventionism |
| 22:36:13
| <mikolalysenko> | C99 fixed a lot of things related to numerical computing |
| 22:36:19
| <chrisdickinson> | is the goal to attract developers from other language communities? |
| 22:36:22
| <mikolalysenko> | it also added complex numbers, etc. |
| 22:36:24
| * dguttman | quit (Quit: dguttman) |
| 22:36:30
| <mikolalysenko> | but was pretty incremental overall |
| 22:36:36
| * paul_irish | quit (*.net *.split) |
| 22:36:37
| * hij1nx | quit (*.net *.split) |
| 22:36:37
| * rch | quit (*.net *.split) |
| 22:36:42
| <mikolalysenko> | C++11 is a pretty radical change though |
| 22:37:00
| <mikolalysenko> | C++11 is a change comparable es5 in js |
| 22:37:29
| <Domenic_> | yes, indeed. but APIs and perf are just part of a triangle; actual language evolution to support those things is important too. |
| 22:38:08
| * Domenic__ | joined |
| 22:38:14
| <Domenic__> | wat irccloud y u fail |
| 22:38:28
| <chrisdickinson> | wouldn't "actual language evolution" usually hinder the "perf" aspect of that triangle? |
| 22:38:42
| <Domenic__> | no!!! |
| 22:38:44
| <Domenic__> | the opposite!!! |
| 22:38:52
| <Domenic__> | tail recursion! |
| 22:38:55
| <Domenic__> | constants! |
| 22:39:01
| <Domenic__> | statically analyzable modules! |
| 22:39:22
| <Domenic__> | generators allowing stack-continuation could eventually be faster than raw callbacks!! |
| 22:39:24
| <chrisdickinson> | mutable prototypes! |
| 22:39:29
| <Domenic__> | the possibilities are great |
| 22:39:29
| <chrisdickinson> | :) |
| 22:40:18
| <Domenic__> | arrow functions avoid creating a new lexical environment! |
| 22:40:25
| <Domenic__> | iterators for lazy list processing! |
| 22:41:08
| <Domenic__> | weak maps and/or private symbols for private data without using the slow closure pattern! |
| 22:41:14
| <Domenic__> | i'll stop there i guess |
| 22:41:59
| <mikolalysenko> | (don't forget binary data types) |
| 22:42:44
| <Domenic__> | !!!!!! |
| 22:43:22
| <Domenic_> | irccloud back yay |
| 22:43:28
| * Domenic__ | quit (Remote host closed the connection) |
| 22:43:55
| * nicholasf | quit (Remote host closed the connection) |
| 22:45:02
| * AvianFlu | joined |
| 22:46:36
| * fotoverite | quit (Read error: Connection reset by peer) |
| 22:46:49
| * fotoverite | joined |
| 22:47:48
| * nicholasf | joined |
| 22:48:12
| * paul_irish | joined |
| 22:48:12
| * hij1nx | joined |
| 22:48:12
| * rch | joined |
| 22:50:00
| <Raynos> | Domenic_: what's your opinion on smaller iterations? |
| 22:50:12
| <Domenic_> | Raynos: what do you mean |
| 22:50:43
| <Raynos> | es6 is pretty cool but its a massive 5 year cycle |
| 22:50:54
| <Raynos> | I would rather have less features in 6 monthly cycles |
| 22:52:48
| * dguttman | joined |
| 22:53:00
| * thl0 | joined |
| 22:53:11
| <Domenic_> | well there's two issues |
| 22:53:22
| <Domenic_> | three i guess |
| 22:53:35
| <Domenic_> | one, yes, i agree, and so does tc39, there was some discussion of how to do this at the last meeting |
| 22:53:56
| <Domenic_> | the i18n group has been working off to the side and producing deliverables |
| 22:54:23
| * thl0 | quit (Remote host closed the connection) |
| 22:55:07
| <Domenic_> | second issue |
| 22:55:45
| <Domenic_> | es6 is was hopefully a bit anomalous as they were adding "foundational" features that other features depended on, i.e. the dependency graph made it difficult to modularize |
| 22:55:54
| <Domenic_> | most prominent examples are modules and unique symbols |
| 22:55:57
| * dguttman | quit (Client Quit) |
| 22:56:18
| <Domenic_> | so hopefully future revisions will have all the base technology in place and they can add things easily |
| 22:56:21
| <Domenic_> | third issue |
| 22:56:26
| <Domenic_> | spec versions don't matter |
| 22:56:37
| <Domenic_> | html5 did a great thing by removing the 5 |
| 22:56:49
| <Domenic_> | nobody now gets upset about large feature dumps in html5.1 |
| 22:56:56
| <Domenic_> | it's just about when things make it into your favorite browser |
| 22:56:58
| <Domenic_> | it's the same with JS |
| 22:57:04
| <Domenic_> | Firefox has tons of ES6 features |
| 22:57:10
| <Domenic_> | IE11 will have some |
| 22:57:17
| <Domenic_> | Safari even has one that nobody else has! |
| 22:57:27
| <Domenic_> | V8 has their flag strategy which seems unfortunate |
| 22:57:39
| <Domenic_> | But yeah, spec versions don't matter |
| 22:57:51
| * fallsemo | quit (Quit: Leaving.) |
| 23:00:50
| * jibay | quit (Remote host closed the connection) |
| 23:01:20
| * st_luke | joined |
| 23:01:31
| * paul_irish | quit (*.net *.split) |
| 23:01:32
| * hij1nx | quit (*.net *.split) |
| 23:01:32
| * rch | quit (*.net *.split) |
| 23:03:01
| * dominictarr | joined |
| 23:03:08
| * dguttman | joined |
| 23:03:19
| <substack> | dominictarr: https://twitter.com/Falkvinge/status/342771685264609281 |
| 23:03:45
| <mbalho> | dominictarr: we need more p2p algorithm node modules |
| 23:03:53
| <mbalho> | dominictarr: find some bittorrent hackers |
| 23:04:15
| <dominictarr> | yes, working on it! |
| 23:04:47
| * paul_irish | joined |
| 23:04:47
| * hij1nx | joined |
| 23:04:47
| * rch | joined |
| 23:05:59
| <dominictarr> | I tried yacy |
| 23:06:16
| <dominictarr> | but it just gobbled my cpu and provided no output |
| 23:06:28
| <mbalho> | we need a telehash equivalent |
| 23:06:39
| <mbalho> | node people need a cluster of nodes |
| 23:07:13
| <dominictarr> | https://npmjs.org/derploy |
| 23:07:21
| <dominictarr> | ^ why is this a 404? |
| 23:12:14
| * tmcw | joined |
| 23:14:09
| * fallsemo | joined |
| 23:14:44
| * tilgovi | quit (Ping timeout: 256 seconds) |
| 23:39:17
| * mikolalysenko | quit (Ping timeout: 248 seconds) |
| 23:46:48
| * defunctzombie_zz | changed nick to defunctzombie |