[00:01] nodejs_v8 has joined the channel [00:01] RayMorgan_ has joined the channel [00:02] nodejs_v8 has joined the channel [00:09] ollie has joined the channel [00:13] pdelgallego has joined the channel [00:18] cloudhead has joined the channel [00:27] unomi has joined the channel [00:27] sudoer has joined the channel [00:31] mikeal has joined the channel [00:31] jespern has joined the channel [00:31] dandean has joined the channel [00:31] alex-desktop has joined the channel [00:31] mattly has joined the channel [00:32] joshthecoder has joined the channel [00:35] Tim_Smart has joined the channel [00:35] inimino: deanlandolt: isNaN in a testing library is probably a terrible idea... [00:35] deanlandolt: inimino: that's what /i/ said :D [00:36] deanlandolt: but i can't remember the nasty details [00:36] inimino: deanlandolt: if you have assert(isNaN( /* do some math here */ )) [00:36] deanlandolt: well, i also said /don't ever use isNaN -- and isaacs is probably right, it's not the end of the world [00:37] inimino: then it doesn't assert that it actually returs NaN, because it could return, e.g. a string, or a regex, or something [00:37] inimino: deanlandolt: but if you're not writing a testing library, it's fine [00:37] deanlandolt: yeah...isaacs was saying you could safely do typeof foo === "number" && isNaN(foo)... [00:37] Tim_Smart: nodejs_v8: isNaN [00:37] nodejs_v8: Tim_Smart: function isNaN() { [native code] } [00:37] inimino: yes [00:37] Tim_Smart: nodejs_v8: isNaN('test') [00:37] nodejs_v8: Tim_Smart: true [00:38] Tim_Smart: nodejs_v8: isNaN('123') [00:38] nodejs_v8: Tim_Smart: false [00:38] inimino: basically it's fine any time you know that typeof is 'number' [00:38] deanlandolt: i seem to remember another complaint...time to dig through email [00:38] jashkenas: isNaN: http://github.com/documentcloud/underscore/blob/master/underscore.js#L521 [00:38] inimino: I don't believe there's any other significant issue with it [00:38] jashkenas: inimino's got it -- first make sure it's a number, then isNaN is what you want. [00:39] inimino: (and the behavior on non-numeric types is by design, though it does catch people by surprise, sometimes) [00:39] deanlandolt: well, per the es5 spec: [00:39] deanlandolt: As the ES5 spec (15.1.2.4) says, "A reliable way for ECMAScript codeto test if a value X is a NaN is an expression of the form X !== X.The result will be true if and only if X is a NaN." [00:39] inimino: that is indeed true [00:40] inimino: but outside of code written by and for ES-geeks, isNaN() is probably more likely to be understood :) [00:40] mahemoff has joined the channel [00:41] Tim_Smart: true === x typeof "number" makes more sense to me [00:41] deanlandolt: heh...just remembered the other oddity that (sorta) breaks isaacs' case... [00:41] deanlandolt: (and i know this is VERY silly)... [00:41] deanlandolt: var foo = new Number(10) [00:41] mikeal: if you pass undefined as either the port or hostname to http.createClient(), it should REALLY throw and exception :) [00:41] ashb: isNaN is safew if you've already done a typeof == "number" test [00:41] deanlandolt: typeof foo === "number" && isNaN(foo) [00:41] deanlandolt: err... [00:42] deanlandolt: sorry, i meant new Number [00:42] morgan has joined the channel [00:42] deanlandolt: boxed numbers break things [00:42] ashb: typeof foo == "object" tho [00:42] inimino: deanlandolt: well, yeah, boxed primitives should never be used and will break all kinds of things [00:42] ashb: depends on the expectation [00:42] deanlandolt: heh...i know...that's the point though [00:43] ashb: they are damn useful in a set of cases [00:43] deanlandolt: they're still numbers and they don't pass isaacs' proposed isNaN test [00:43] inimino: I'm of the opinion that using them is always a mistake [00:43] deanlandolt: aye, but perhaps just as much so as isNaN :D [00:43] inimino: but they're not really numbers anymore, they're objects :) [00:43] ashb: boxed Strings i find particularly useful [00:45] deanlandolt: inimino: fair enough...just dropping down into pedantism to better my argument ;) [00:45] ashb: inimino: btw how much have oyu been working on your PEG in the past few months? [00:45] inimino: ashb: tons [00:45] ashb: what's new? [00:45] inimino: ashb: but not a lot to show for it yet [00:45] jed has joined the channel [00:45] ashb: heh i know that [00:45] inimino: what's new is a new codegen which lays the groundwork for streaming [00:45] ashb: inimino: got a nother parsing project. its even simpler than my markdown cases [00:46] ashb: any error handling? [00:46] ashb: *better [00:46] inimino: but I need to make it smarter so that streaming can be automatic [00:46] inimino: not yet... [00:46] inimino: well, actually that's not quite true [00:47] inimino: but yeah, in practice it's true... there's nothing exposed in a nice user-friendly API yet [00:48] inimino: I'll probably blog about what I've done so far on the streaming stuff and then work on expanding the API a little [00:50] inimino: to make what's there now more usable [00:50] inimino: getting the streaming stuff really done right is going to take a bit of time [00:52] mikeal: why doesn't the http client include the message? [00:52] inimino: mikeal: it's an event stream [00:53] mikeal: but it should be parsed before the headers, and the headers are all parsed and in the response [00:53] mikeal: i mean, i can pull it out myself, but it's kind of annoying since the statusCode is before it and the headers are after and they are both parsed in to the response object for you [00:54] inimino: I'm confused [00:54] inimino: what do you mean by "the message"? [00:54] inimino: I thought you meant the entity body [00:54] mikeal: statusMessage [00:54] inimino: oh, you mean the text after the status code? [00:55] mikeal: sorry [00:55] mikeal: reasonPhrase [00:55] mikeal: it's called the "message" in all the Python http libraries [00:55] mikeal: yes [00:55] inimino: oh, I see [00:56] rektide: jesus christ, promises are gone? [00:56] rektide: frak me [00:56] mikeal: yeah, we've all been updating code for a few days :) [00:56] rektide: i didnt really understand where coroutines came in and made everything crazy [00:57] rektide: why promises had to go [00:57] mikeal: they aren't coroutines [00:57] mikeal: they are "continuables" [00:57] inimino: rektide: coroutines are why wait() had to go [00:57] mikeal: wait() was going to go anyway tho [00:57] mikeal: ry has been talking about removing that for a quite a while [00:57] inimino: yes [00:57] rektide: i dont have any wait()'s [00:58] deanlandolt: rektide: you can easily get promises back in your own code [00:58] mikeal: they invite abuse and bad things, and there were lots of annoying bugs [00:58] rektide: it is a little annoying erlang is the only runtime where sleeping a thread is a-ok [00:58] inimino: yeah, ryah released the exact code that was in Node somewhere, so if you liked existing node promises you can import them [00:59] mikeal: rektide: it's not a thread [00:59] mikeal: is a "process" [00:59] mikeal: and the entire VM and language are built to accomodate it [00:59] inimino: rektide: it'd be ok if we had threads ;-) [00:59] mikeal: erlang doesn't have threads either [01:00] inimino: well, it doesn't call them that [01:00] dnolen has joined the channel [01:00] mikeal: threads share memory, erlang processes don't [01:00] inimino: but they're close to what lots of people would call green threads [01:00] mikeal: anything you put in a process you have to pass messages to in order to communicate, you can't use shared memory [01:00] rektide: well, wait() [01:00] inimino: they can share memory, it's just not observable :) [01:00] mikeal: when you do that, bad things happen :) [01:01] mikeal: but erlang processes are way better than threads [01:01] mikeal: because they map over n cores [01:01] mikeal: x amount of processes will use between 1 and 32 cores depending on how many are on the box [01:03] mrd`: mikeal: pthreads do that too, or are you talking about some other threading model? [01:04] mikeal: pthreads don't use multiple cores [01:04] mikeal: nthreads do [01:04] mrd`: NPTL pthreads do. [01:05] mikeal: sharing memory over cores is a bad idea tho [01:05] davidjrice: yo yo, [01:05] davidjrice: anyone using node + fab + paperboy to serve assets? [01:05] mrd`: I'm not claiming it's not; I'm just saying threads are able to use multiple cores too. [01:06] mikeal: are you sure NPTL threads using multiple cores [01:06] mikeal: i think LinuxThreads do [01:06] mrd`: Yes. [01:06] mikeal: because they don't share a pid [01:06] mikeal: and are essentially implemented as separate processes [01:07] mikeal: With NPTL, all of the threads in a process are placed in the same thread group; all members of a thread groups share the same PID. NPTL does not employ a manager thread. NPTL makes internal use of the first two real-time signals; these signals cannot be used in applications. [01:07] davidjrice: getting performance like 15 / 16 seconds to download jquery [01:07] creationix has joined the channel [01:08] mikeal: i'm just scratching my head trying to figure out how they are going to use multiple cores while sharing a PID [01:08] mrd`: From the NPTL design paper: "Effective Use of SMP: One of the main goals of using threads is to provide means to use the capabilities of multi-processor systems. Splitting the work in as many parts as ther are CPUs can ideally provide linear speedups." [01:09] mrd`: A pid specifies a group of threads. [01:09] davidjrice: 1 minute 2 seconds to load a 315kb page, 26 requests... [01:09] davidjrice: does node bottleneck on the file system level? [01:09] creationix: anyone know of a good js code highlighter, shjs is gpl3 and pygments has too much overhead from the python runtime [01:09] mikeal: right but the kernel usually keeps a system process to a single core [01:10] mikeal: davidjrice: node has a threadpool to access the filesystem so that you can make non-blocking calls to the filesystem [01:10] mrd`: mikeal: Not when there are multiple threads. :) [01:10] mikeal: there is a selection of synchronous file operations that you can do that will block if you need them [01:10] davidjrice: creationix: http://www.hiliteme.com/ ? or gist.github.com ? perhaps an api like that might be a good look [01:11] davidjrice: mikeal: okay, so I'm wondering how I get such poor performance! [01:11] creationix: davidjrice: I'm looking for something I can access from a node program, ideally I would be able to package it as a module [01:11] creationix: gist.github.com uses pygments [01:11] mikeal: so, Python and Ruby both use pthreads now [01:11] mikeal: and both don't map, ever, over multiple cores [01:11] mrd`: mikeal: Python at least is because of the GIL. [01:11] jashkenas: creationix: the issue with looking for an in-JS highlighter is that they're all quite DOM-bound. [01:12] mikeal: unless you use a special library that hacks it with a shared semephore and a forked interpreter [01:12] mrd`: mikeal: I'm not familiar with Ruby to say. [01:12] mikeal: also, if this is the case, I can't see how the majority of cases would be performant [01:12] creationix: jaskenas: hmm, then I wonder how I can speed up pygments processing time. Spawning a subprocess for every snipped of code is killing me [01:12] ashb: jashkenas: yeah - there's hilight.js, but its very tied to DOM [01:13] jashkenas: creationix: what's it for? [01:13] creationix: node-blog [01:13] ashb: ( http://softwaremaniacs.org/soft/highlight/en/ ) [01:13] mikeal: i could see LOTS of threads being performant, but when you have just a few the overhead wouldn't be worth the optimization [01:13] creationix: right now it's using shjs in the browser, but I want to highlight server-side to make the page load faster [01:13] ashb: oh it has a bzr reop up now. thats new [01:14] mikeal: creationix: all the existing javascript libraries for syntax highlighting suck [01:14] rektide: i was relatively happy with codemirror [01:14] mikeal: the only one that kind of works is tightly coupled to bespin [01:14] mrd`: mikeal: http://www.ibm.com/developerworks/linux/library/l-posix1.html <-- first paragraph "And, on multiprocessor systems, threads are actually able to run simultaneously, just like two or more processes can." [01:14] rektide: http://marijn.haverbeke.nl/codemirror/ [01:14] jashkenas: creationix: ran across this earlier today, but don't know anything about it: http://matt.might.net/articles/lexing-and-syntax-highlighting-in-javascript/ [01:14] rektide: but again, stupidly tightly coupled the the dom [01:15] mikeal: you can't really fault them for using the DOM [01:15] mikeal: they started this before node was even around [01:15] ashb: jashkenas: he doesn't link to it tho :/ [01:15] ashb: mikeal: no - but they could have done SoC better [01:15] jashkenas: speaking of node not being around -- what do y'all tell Windows users who want to try Node? [01:15] mikeal: haha, first header "Threads are fun"….. no they aren't [01:16] ashb: oh no - he just has a stupid add in the middle [01:16] creationix: jashenas: either help us port it or run a VM [01:16] jashkenas: Is there a second-best server-side JS implementation that you point them towards? [01:16] ashb: jashkenas: if they just want ssjs or a JS interpreter tell them to try flusspferd :) [01:16] isaacs has joined the channel [01:16] mikeal: windows is going to happen eventually [01:16] ashb: we support windows [01:16] mikeal: i don't think it'll be super fast [01:17] ashb: jashkenas: point windows users towards http://flusspferd.org/ until node gets win32 support ;) [01:17] jashkenas: ashb: are you planning on having flussperfd support the Node API? Or just CommonJS? [01:18] ashb: jashkenas: somewhere in the middle [01:18] ashb: jashkenas: part of the problem is we can't build an event loop in as tightly as we have people embeddeding it in games that have their own loop/event ideas already [01:18] jashkenas: interesting. thanks. I'll float the idea with the person who was asking and see if he wants to do the legwork. [01:18] cloudhead: I tell them to install linux [01:18] ashb: i've started playing artound with boost.asio (since we use boost a lot) [01:19] ashb: its just not core yet [01:19] ashb: i do have mdeium term plans to get evented into the core [01:19] ashb: but it needs a few abstraction layers to not break some of our users [01:20] mikeal: this is neat [01:20] bpot has joined the channel [01:21] ashb: what is? [01:24] RayMorgan has joined the channel [01:28] bryanl has joined the channel [01:32] Tim_Smart: What do you guys think about Riak? [01:33] Tim_Smart: has a http interface :o [01:34] jan____: Riak is awesome :) [01:36] Tim_Smart: Would be good for async stuff [01:36] jan____: unlike couch :) [01:37] davidjrice: heh [01:37] davidjrice: so, anyone using node-paperboy in production? [01:40] Tim_Smart: davidjrice: I tried it, but I decided that node isn't very good for serving static content [01:40] Tim_Smart: I'll probably use nginx for that stuff [01:41] davidjrice: Tim_Smart: have you put nginx in front of node? [01:41] Tim_Smart: yeah that's the idea [01:42] Tim_Smart: you can send X-Redirects as the response to dynamically point to static files as well [01:42] Tim_Smart: with nginx [01:42] davidjrice: interesting [01:43] Tim_Smart: Otherwise node is slower than apache at serving static content by a reasonably large margin [01:45] davidjrice: Tim_Smart: I hit > 1 min for 300k [01:46] inimino: davidjrice: it's not that slow [01:46] inimino: not even close... [01:47] Tim_Smart: Sorry the difference between apache and node.js was smaller than I remembered [01:47] inimino: node, I mean... I don't know about node-paperboy, but maybe something in your setup or testing is off? [01:47] Tim_Smart: from a while back http://gist.github.com/293015 [01:47] Tim_Smart: I used paperboy for the test [01:47] inimino: it's a few percentage points either way [01:47] inimino: 300k in a minute is a sign of some sort of weird major malfunction [01:47] Tim_Smart: about 100 req/s difference [01:48] jashkenas: that's pretty incredible. I wonder what the comparative RAM footprints are on that benchmark. [01:49] charlenopires has joined the channel [01:50] brainproxy has joined the channel [01:50] spot__: Is there a clean command line argument parser/handler out there someone has written, or should I quickly roll my own? [01:51] jashkenas: spot__: there's this one. http://github.com/jfd/optparse-js [01:52] jashkenas: I have a much simplified 80-line version that I'm using for CoffeeScript, here: http://github.com/jashkenas/coffee-script/blob/master/src/optparse.coffee [01:52] spot__: jashkenas, thanks! [01:53] brainproxy has joined the channel [01:53] Tim_Smart: jashkenas: With Coffeescript, is it possible to quickly change the way it re-writes certain expressions? Or is a case of hacking at source? [01:54] brainproxy has joined the channel [01:54] jashkenas: Tim_Smart: I'm not sure what you mean? Want to take it over to #coffeescript? [01:54] Tim_Smart: yeah [02:11] binary42 has joined the channel [02:17] rektide: why oh why is this laptop's lighttpd not running? :/ blah [02:19] rektide: way to silently exit without throwing any kind of debug info [02:32] bryanl has joined the channel [02:42] bentomas has joined the channel [03:04] bentomas has left the channel [03:04] brapse has joined the channel [03:10] stephenlb:
0,0 z-index 900> // for Modalness [03:10] stephenlb:
0,0 z-index 1000> [03:15] dandean has joined the channel [03:15] adamv has joined the channel [03:19] stephenlb: : / [03:19] stephenlb: srry bout that, must have pased wrong window. [03:22] rictic has joined the channel [03:24] cdorn has joined the channel [03:25] CIA-77: node: 03Ryan Dahl 07master * rdc04162 10/ doc/api.txt : Add not about nextTick and setTimeout(fn, 0) - http://bit.ly/bkaN6E [03:25] CIA-77: node: 03Ryan Dahl 07master * rf0f2d2e 10/ doc/api.txt : Fix readdirSync in docs - http://bit.ly/cBVvqZ [03:25] CIA-77: node: 03Rasmus Andersson 07master * rb57d946 10/ (4 files in 3 dirs): [03:25] CIA-77: node: added fs.link, fs.symlink, fs.readlink [03:25] CIA-77: node: including sync versions and complete tests - http://bit.ly/bvHkJF [03:26] RayMorgan has joined the channel [03:39] hooopy has joined the channel [03:39] hooopy: hello?(!) [03:41] Tim_Smart: hi?! [03:42] hooopy: hello [03:47] hooopy: dang [04:00] RayMorgan_ has joined the channel [04:03] gf3 has joined the channel [04:07] dekz has joined the channel [04:11] sahnlam has joined the channel [04:11] bentomas has joined the channel [04:28] steadicat has joined the channel [04:36] chakrit has joined the channel [04:44] bpot has joined the channel [04:48] steadicat has joined the channel [04:49] dandean has joined the channel [05:02] Tim_Smart: gf3: I'll be chucking that IRCd code here http://github.com/Tim-Smart/nodirc [05:05] gf3: Tim_Smart: watched [05:05] Tim_Smart: :) [05:05] Tim_Smart: I'm deciding the db atm [05:08] kriszyp has joined the channel [05:23] rauchg has joined the channel [05:24] JoePeck: Tim_Smart: _Ray_ from ##javascript started a neat javascript irc bot [05:24] Tim_Smart: Yeah I know about that one, the v8 evaler? [05:24] JoePeck: yea [05:24] Tim_Smart: nodejs_v8: Object [05:24] nodejs_v8: Tim_Smart: function Object() { [native code] } [05:25] Tim_Smart: Yeah that is the one I made [05:25] JoePeck: I also have a Ruby one that worked with jsc, v8, spidermonkey, and rhino (it just spawned a process and ran their shells) [05:25] JoePeck: if you want code to look at... but I think your bot will be different [05:26] mikeal has joined the channel [05:26] Tim_Smart: Yeah I can get you the source if you want it [05:38] dnolen has joined the channel [05:47] mattly has joined the channel [06:03] steadicat has joined the channel [06:07] jspiros has joined the channel [06:07] mahemoff has joined the channel [06:24] bentomas has left the channel [06:34] RayMorgan has joined the channel [06:42] kennethkalmer has joined the channel [06:42] cmlenz has joined the channel [06:43] JimBastard has joined the channel [06:43] JimBastard: hey whats up Tim_Smart [06:43] Tim_Smart: Yo JimBastard, not too much atm. Reading up about H.264 and Ogg Theora [06:50] mikeal: the next version theora is suppose to be great [06:51] Tim_Smart: Hopefully it knocks H.264 off its perch, I'm starting to really hate all its licensing crap [06:59] mikeal: yeah, being on some of the major browsers is kicking it in to gear [06:59] mikeal: it's in Chrome and Firefox now [07:00] mikeal: i don't think it's going to win tho [07:00] mikeal: i think h.264 will still dominate this generation of codecs [07:00] mikeal: but the next generation will go to something open [07:02] Tim_Smart: yeah, hopefully the 'next generation' is closer than expected :D [07:03] mikeal: theora is just too late to the embedded game [07:03] mikeal: there are some good chipsets now, but h264 chipsets are down to pennies [07:03] Tim_Smart: hmm yeah [07:03] mikeal: and apple just got the instructions in to the A4 [07:04] mikeal: so it doesn't even need a seperate chipset [07:04] mikeal: but just the fact that you *can* buy theora chipsets is a big win [07:04] mikeal: it means the next time around their is a community that knows how to do this [07:04] mikeal: s/their/there [07:05] mikeal: and a next generation codec can be built much faster as an open source project then as a standard in a proprietary working group :) [07:05] Tim_Smart: Yeah ogg is based on a kinda bad code base apparentl;y [07:06] mikeal: vorbis is old [07:06] mikeal: there are some good people working on theora now tho [07:06] mikeal: before i left mozilla i talked to one of the developers at Mozilla who just does