[00:09] Biscuits has joined the channel
[00:09] Biscuits: Hi, would anyone know if there's been any work done on porting Node.js to Win32 ?
[00:10] liefy_ has joined the channel
[00:13] orlandov: Biscuits: someone can correct me if i'm wrong, but i think there hasn't been a lot of work towards that end
[00:14] Biscuits: Doesn't seem like it
[00:14] orlandov: i think someone built a livecd with node, so you could run it in a VM
[00:14] Biscuits: All I could find was "Node eventually wants to support all POSIX operating systems (including Windows with MinGW)"
[00:14] ear1grey has joined the channel
[00:14] Biscuits: Nah, it's ok, I've got an Ubuntu server running at home, so I can use that
[00:14] Biscuits: I was just wondering if i'd be able to write windows apps using it
[00:14] orlandov: odds are it'll be better in unix land anyway :)
[00:15] orlandov: </bias>
[00:19] SteveDekorte2 has joined the channel
[00:20] JimBastard has joined the channel
[00:20] SteveDekorte2: are there any database bindings for nodejs?
[00:21] orlandov: SteveDekorte2: http://wiki.github.com/ry/node
[00:21] JimBastard: there are a few
[00:21] orlandov: check out the wiki
[00:23] SteveDekorte2: thanks - looks like those are clients but not bindings - was hoping for a BDB binding
[00:24] SteveDekorte2: I guess the TokyoTyrant client might do, but would like to avoid the overhead
[00:24] orlandov: SteveDekorte2: yeah, the tricky part is using the databases in a non-blocking way
[00:24] orlandov: or rather, writing the drivers in that way.
[00:24] SteveDekorte2: orlandov: not a problem for a key/value 
[00:24] SteveDekorte2: *key/value db 
[00:25] orlandov: afaik everything has to be done non-blockingly
[00:25] orlandov: even file io
[00:25] SteveDekorte2: orlandov: only if it's going to block for a long time, right?
[00:26] orlandov: someone can correct me if i'm wrong but i think the whole point is to not ever block
[00:26] SteveDekorte2: if it occasionally "blocks" for a milisecond, that's not a problem, right?
[00:26] SteveDekorte2: well everything blocks for some amount of time - even a function that adds two numbers
[00:27] orlandov: well, i'm still a noob to all of this, but if it happens to block at all, it will hold up other requests
[00:27] orlandov: since node is single threaded
[00:27] orlandov: SteveDekorte2: that's not the same as blocking though
[00:27] SteveDekorte2: right, that's fine
[00:27] SteveDekorte2: orlandov: oh?
[00:27] orlandov: blocking means you're waiting for an event on afile descriptor
[00:27] orlandov: but while you're waiting you can be doing other stuff
[00:27] orlandov: you can't do other stuff if you're computing some value
[00:27] SteveDekorte2: nodejs is single threaded, right?
[00:27] orlandov: i think so...
[00:28] SteveDekorte2: I don't see the difference other than the length of the blocking time then
[00:28] orlandov: the difference is while your script is waiting for a reply from the server it could be doing other stuff
[00:28] SteveDekorte2: but I understand why it would be a problem for long blocks
[00:28] SteveDekorte2: just as a function that takes a long time to run would be unacceptable
[00:29] ryah: SteveDekorte2: hey
[00:29] SteveDekorte2: hey ryah 
[00:29] frodenius: you can even block for long times
[00:30] SteveDekorte2: frodenius: does nodejs support coroutines?
[00:30] frodenius: no
[00:30] frodenius: javascript in general has no coroutine support
[00:31] ryah: "poor man's coroutines"
[00:31] Biscuits: Hmm, what you could do is split functions that take a long time off another Node.js instance, and communicate with that using JSON.
[00:31] Biscuits: That way your main server doesn't block
[00:32] inimino: Workers!
[00:32] Biscuits: Yeah, but workers aren't implemented yet, are they 
[00:32] ryah: SteveDekorte2: fake coroutines - no multiple execution stacks, when you yield the next execution stack grows on top of the last
[00:32] Biscuits: ?
[00:33] ryah: SteveDekorte2: which has the nice properly of allowing people do simple promise.wait()  - but is not generally usable in busy process
[00:34] SteveDekorte2: for my purposes, serial requests with tiny blocks are fine - was hoping to find a bdb binding though. The other option is Lua, whch has real coroutines and is faster.
[00:35] ryah: gtg
[00:35] inimino: Biscuits: right
[00:35] Biscuits: Hmmm
[00:36] Biscuits: If you have some really really intense stuff, you could even just fire up a Node.js sub-process and communicate using stdin/stdout
[00:36] orlandov: yeah that would be easy to make non-blocking
[00:37] inimino: yes
[00:39] Biscuits: Hmm, btw, I'm trying to build Node.js on my Ubuntu 9.100 x64 server, and I get the following error upon "make"
[00:39] Biscuits:  error: cxx is not a valid task generator -> ['command-output', 'cmd_output', 'cc', 'cmd', 'subst', 'copy']
[00:40] Biscuits: Would anyone have any clue how to fix that ?
[00:41] inimino: no :(
[00:56] jmettraux has joined the channel
[00:59] dschn has joined the channel
[01:09] Biscuits: Hmm, what's the proper way to have an object implement the EventEmitter class ?
[01:11] orlandov: Biscuits: i think through inheritance?
[01:11] orlandov: sorry, i'm looking up the link now :)
[01:11] Biscuits: Hmm, in that case, what'd be the proper way to do multiple inheritance then :p?
[01:13] inimino: don't :)
[01:14] JimBastard: whose getting inheritance? i want me some of that internet money
[01:14] Biscuits: Hmmm btw, is there any reason to use either x.prototype=new y(); or function x() { y.apply(this,[]); }; x.prototype.prototype=y.prototype; ?
[01:15] orlandov: is it like this? sys.inherits(MyClass, process.EventEmitter);
[01:15] Biscuits: To me the second one seems clearer as the constructor for y isn't unneededly called
[01:15] elliottcable: inimino: Hey, you there?
[01:15] inimino: 
ACTION gives JimBastard one standard IRC clam

[01:15] Biscuits: Hmmm, can't find sys.inherits in the docs :S
[01:15] inimino: elliottcable: yeah
[01:15] elliottcable: Biscuits: O_O
[01:15] elliottcable: Biscuits: Ranjani? o_o
[01:15] Biscuits: ?
[01:16] elliottcable: inimino: That problem you pointed out, I don’t see how it’s a problem.
[01:16] elliottcable: inimino: http://gist.github.com/241405 lines 10 and 11, zand then 37… it doesn’t really matter what the constructor’s old prototype is, unless I’m confused
[01:18] inimino: elliottcable: the problem wasn't to do with what the constructor's prototype was, but with what the constructor was
[01:18] elliottcable: Biscuits: sorry, thought you were someone I knew
[01:18] elliottcable: inimino: how do you mean?
[01:20] inimino: elliottcable: the only reason this.constructor actually gets the constructor is because by default there is a constructor property created on the prototype object which is created when you create a new function
[01:21] elliottcable: yes, but if it’s not there, won’t it fall upwards the tree to a place where it’s defined?
[01:21] elliottcable: thus, it will always be defined
[01:21] inimino: elliottcable: well, yes, though it'll normally be on Object.prototype in that case (and then it won't work)
[01:22] elliottcable: hrm?
[01:22] inimino: (and it'll fall through your extra new Function stuff)
[01:22] elliottcable: I must be very confused.
[01:23] JimBastard: http://www.maraksquires.com/articles/2009/11/19/front-end-development-manifesto/
[01:23] JimBastard: poop
[01:24] inimino: in case there isn't a 'constructor' own property on 'this' (or another intermediate prototype object), then this['constructor'] will be looking at Object.prototype.constructor which is Object
[01:24] elliottcable: yep
[01:24] elliottcable: and?
[01:25] inimino: and then the assignment on line 11 won't work and it'll go through the code path that tests for that
[01:26] elliottcable: how will it miss the path that tests for that, if 11 doesn’t work? o_O
[01:26] inimino: it won't
[01:26] inimino: sorry, I shouldn't have said "fall through", that was unclear
[01:26] elliottcable: ;ah, okay
[01:27] elliottcable: so there’s no problem? or am I missing something?
[01:27] jmettraux has left the channel
[01:27] inimino: there's no problem, except that it's kind of ugly I think to rely on something failing and then testing for it having failed in cases where you could have tested directly for the condition that caused it to fail
[01:28] elliottcable: ah
[01:28] elliottcable: yes, but I don’t want to do that *unless* it fails, you see?
[01:28] inimino: I'd probably test for this.constructor == Object first
[01:28] elliottcable: if an interpreter somehow works around it or something…
[01:28] elliottcable: or if something *else* fails…
[01:28] inimino: well, it's just a matter of taste
[01:28] elliottcable: see, the only case in which I want to use a constructor *other* than the one defined by the user…
[01:29] elliottcable: … is the case in which `this['constructor']['prototype'] !== this`, yes?
[01:29] elliottcable: it’s less testing to see if line 11 failed, and more testing to see if we need to use our own constructor
[01:29] inimino: yes
[01:29] elliottcable: inimino: yeah, but taste is ridiculously important when it comes to programming. Better programmers == better taste == better code
[01:30] inimino: well, there's probably no way to do this kind of inheritance hackery that's going to please everyone's taste, least of all mine ;)
[01:30] JimBastard: shit time to clean up http://github.com/Marak/node_debug and fix the spaghetti structure
[01:30] JimBastard: fu.js is a little strange with setting up resources
[01:30] JimBastard: for the front-end
[01:31] JimBastard: i gotta put a big warning on it too about leaving it in debug mode....maybe add a password
[01:31] elliottcable: lol
[01:31] JimBastard: eval() :-(  :-(
[01:31] inimino: elliottcable: anyway, it looks like it should work as you have it
[01:31] elliottcable: inimino: well, at the least, do you understand wy I check for the existence of this['constructor']['prototype'], instead of checking whether this['constructor'] is something known-dangerous?
[01:32] inimino: elliottcable: of course
[01:33] inimino: elliottcable: and probably arguments could be made for doing either what you have, or putting the == Object test instead, or doing both, but if what you have works I wouldn't worry about it
[01:33] elliottcable: coo’ coo’
[01:34] jed has joined the channel
[01:34] inimino: (actually I thought you had decided not to worry about yesterday ;-)
[01:35] elliottcable: huh?
[01:35] elliottcable: I really have no steady internet access
[01:35] inimino: er
[01:35] elliottcable: depends when I can find a place with good EDGE connectivity
[01:36] elliottcable: wherein my SSH will actually remain responsive for an extended period of time
[01:36] inimino: s/about/about it/
[01:37] elliottcable: I’m a perfectionist. Everything has to be purrfect.
[01:37] inimino: I meant I thought you had already decided not to worry about that other case
[01:37] inimino: hehe, ok :)
[01:38] inimino: elliottcable: so you drop semicolons on a single statement inside braces, and nowhere else?
[01:39] elliottcable: Other way around, actually.
[01:39] elliottcable: I use semicolons (on *all* lines) when there are multiple statements inside a single scope.
[01:39] elliottcable: even the last line, on which it’s not necessary… for consistency.
[01:40] inimino: yeah, that's what it looked like
[01:40] inimino: interesting
[01:42] elliottcable: (-:
[01:44] inimino: I like to see people pursuing their own JavaScript formatting style :-)
[01:45] okito has joined the channel
[01:46] elliottcable: hah, I certainly do that.
[01:47] inimino: yeah, me too :)
[01:47] inimino: JSLint non-users, unite! ;)
[01:49] voodootikigod: !log
[01:49] inimino: that should probably be in the /topic
[02:00] inimino: voodootikigod: are those logs served by node.js?
[02:01] voodootikigod: yea
[02:01] voodootikigod: and recorded by node
[02:01] voodootikigod: the_undefined hacked it up
[02:04] inimino: nice
[02:07] nebopolis has joined the channel
[02:19] rtomayko has joined the channel
[02:28] gwadeloop has left the channel
[02:34] JimBastard: node_debug updated, anyone wanna check it out? next iteration will be code syntax highlighting on the consoleInput
[02:34] JimBastard: http://maraksquires.com:8080/
[02:34] JimBastard: http://github.com/Marak/node_debug
[02:34] JimBastard: feedback / suggestion welcome
[02:38] JimBastard: anyone?
[02:41] elliottcable: Oh, hey
[02:41] elliottcable: voodootikigod: you?!
[02:41] elliottcable: anyway, who was saying recently that my acquire() system is too generic, and doesn’t decide on an API?
[02:41] elliottcable: I understand that sentiment, but I really want all the functionality I wrote up in there. And I like the diversity of functionality.
[02:41] elliottcable: But I’m open to suggestions to re-work my API design.
[02:43] elliottcable: really, really need to get teddy.js working so Ican use it to spec acquire /-:
[02:44] Bluebie has joined the channel
[02:45] elliottcable: voodootikigod: where do I know your name from?
[02:45] Bluebie: I AM HERE!
[02:45] Bluebie: we can start the party now.
[02:45] Bluebie: holy woah, that's a lot of people
[02:45] elliottcable: voodootikigod: I mean, I know we exchanged tweets earlier, but why am I following you in the first place
[02:45] elliottcable: Bluebie: Node.js is a Big Deal™ now
[02:45] Bluebie: they should have made it a Big Deal™ after the api had solidified
[02:45] Bluebie: oh wellity
[02:46] elliottcable: heh
[02:46] elliottcable: oh shit ryah_away I need to talk to you about that
[02:46] Bluebie: can't move a conference to suit a tiny javascript runtime's development cycle
[02:46] Bluebie: he's on vacation!
[02:46] elliottcable: ryah_away: before you solidify the API, I want to try to convince you to get rid of Promise
[02:46] inimino: where would be the fun in that?
[02:46] inimino: elliottcable: in favor of?
[02:46] elliottcable: inimino: EventEmitter
[02:46] Bluebie: unicorns.
[02:47] inimino: unicorns beat promises
[02:47] elliottcable: inimino: UnicornPromise
[02:47] Bluebie: promise works for manythings, way I see it, we should be unixy, what with a few little specialised event doodads for various tasks, rather than the One True Event Dispatcher
[02:47] inimino: elliottcable: but why not have a simpler EventEmitter for the common only-two-interesting-events case
[02:48] elliottcable: because I can’t use EventEmitter for that.
[02:48] Bluebie: you can't?
[02:48] elliottcable: Okay, I guess correction. I don}t really care if Promise sticks around
[02:48] Bluebie: we seem to be able to..
[02:48] elliottcable: but I want to see EventEmitter do everything that Promise does, in a more flexible way
[02:48] inimino: agreed
[02:48] inimino: elliottcable: why not?
[02:48] elliottcable: as it is, I can’t .wait() an EventEmitter; which is absolute essiental; I can’t prmise that no more events of any type will come after events of a certain type come
[02:49] elliottcable: specifically, I have to use a Promise for stuff in acquire()
[02:49] elliottcable: which is really annoying, because it only supports one type of error
[02:49] elliottcable: and I need to emit various error events
[02:49] inimino: ah
[02:49] inimino: well, there only is one type of error
[02:49] inimino: 'something didn't work'
[02:49] Bluebie: makes sense
[02:49] elliottcable: but I need to be able to say, just like a Promise says that only one error or success will ever be emitted, that only one type of error or a success will be emitted
[02:49] inimino: if you need more specificity you get it from whatever you pass back to the handler no?
[02:49] voodootikigod: elliottcable: hmm
[02:49] voodootikigod: dont know
[02:49] elliottcable: inimino: not good enough.
[02:50] elliottcable: inimino: trust me, having to `switch` against a billion possible Error objects is a *huge* bitch; not to mention that I have to pre-build hte Errro object
[02:50] Bluebie: perhaps a VaguePromise could support any event, but only one time use, and allow .wait() on anything
[02:50] elliottcable: Bluebie: fuck no, not *another* object in the API
[02:50] inimino: hm, ok
[02:50] inimino: 
ACTION would need to see use cases, I guess

[02:50] Bluebie: yes, another object!
[02:50] elliottcable: Bluebie: EventEmitter does everything we need, we just merge the nice stuff from Promise back into it
[02:50] inimino: heh
[02:50] Bluebie: 
ACTION likes the name too much

[02:50] Bluebie: aww, okay
[02:50] Bluebie: need more objects!
[02:50] elliottcable: anyway, for that, we also need multiplexed events
[02:51] elliottcable: i.e. an "notFoundError" even also triggers listeners for the "error" event
[02:51] elliottcable: and so on and so forth
[02:51] Bluebie: object orientedness is a good thing right? so stands to reason more objects = more points?
[02:51] voodootikigod: elliottcable: you always been in alaska?
[02:51] inimino: well, I can't see anything API-wise wrong with having .waitFor(foo) except for one little fact
[02:51] elliottcable: and then anye vent which triggers the "error" event, or the "success" event, also promises that no more events wil lbe emitted
[02:51] elliottcable: voodootikigod: yep
[02:51] inimino: which is that .wait() should probably not be in node at all from a theoretical purity perspective
[02:51] Bluebie: wait is excellent
[02:51] elliottcable: inimino: I understand that, but it’s too useful for thingsl ike acquire()
[02:51] Bluebie: everybody loves wait
[02:51] inimino: so spreading the .wait evil into other APIs might not fly
[02:52] Bluebie: only doofuses think that a language should try to force people to program a specific way even when it doesn't make any sense at all, it's a scientific fact
[02:52] voodootikigod: Cliff or dave?
[02:52] Bluebie: from the institute of doofusology's 2008 report..
[02:52] elliottcable: really, I’m just looking for the Promise-y-ness of Promise for EventEmitter, I can live without wait()
[02:52] inimino: 
ACTION hasn't ever used .wait

[02:52] inimino: in fact I'd much prefer it be dropped
[02:52] elliottcable: Bluebie: uh, I think that.
[02:52] elliottcable: as apparently does inimino/
[02:52] Bluebie: 
ACTION is glad ryah doesnt <_<

[02:53] elliottcable: actually, that’s the motivation for all of the way I code. The point is to use psychology on the people using my libraries, to make them code the way I want them to, for their own good.
[02:53] elliottcable: the entire point is to make thigns that they *shouldn’t* do difficult, and things they *should* do easy.
[02:53] elliottcable: although it’s a few orders of magnitude more complex than that.
[02:53] inimino: quite ;)
[02:53] inimino: the fewer people use .wait, the sooner we can work out the API issues with getting real async programming working right
[02:53] elliottcable: anyway, .wait() is okay by me… inside the first three lines of a program.
[02:53] Bluebie: frankly, I LIKE not loading dependancies like this. require('a.js').addCallback(function() { require('b.js').addCallback(function() { require('c.js').addCallback(function() { require('d.js').addCallback(function() {.......
[02:53] elliottcable: when it’s requiring libraries and whatnot, before it gets into any meat loops or anything.
[02:54] Bluebie: yeah
[02:54] Bluebie: point is that async is so easy and natural that there isn't really any great motivation to use wait
[02:54] inimino: I don't like the pseudo-pragmatic "async is hard, lets just wait" approach
[02:54] inimino: Bluebie: neither do I, but that's an API/convenience library issue
[02:54] Bluebie: and even if people do, it's a performance hit, but it doesn't halt the event loop, the program keeps churning
[02:55] Bluebie: async isn't hard in node?
[02:55] elliottcable: anyway people, need input on acquire, so let’s move to that:
[02:55] inimino: if it's syntactically ugly and paintful to do things asynchronously, we should focus on fixing that
[02:55] elliottcable: what should I do to clean up the API?
[02:55] elliottcable: currently, I have three whole APIs under the acquire. namespace.
[02:55] Bluebie: I don't think typing 'function() {' is so difficult that it'd motivate people to cut corners in code quality, it's simply a matter of the right tool for the right job
[02:56] elliottcable: I could perhaps move the import-related stuff into its own namespace, but I hesitate to introduce *two* root-level methods on process
[02:56] inimino: Bluebie: async does undoubtedly make some things harder, at least with the current APIs
[02:56] Bluebie: I hereby declare my doubt
[02:56] elliottcable: wizard sleeves make for some *freaking great* air-conducting.
[02:57] elliottcable: 
ACTION madly air-conducts

[02:57] Bluebie: :)
[02:57] Biscuits: Hmmm, don't suppose someone has already written an XML parser for use in Node.js ?
[02:57] elliottcable: yes?
[02:57] elliottcable: Bluebie: libxmljs
[02:57] elliottcable: oops, Biscuits ^^
[02:57] elliottcable: Biscuits: it works great, mind you. I’m using it in my XMPP server.
[02:58] elliottcable: Biscuits: the API needs some re-thinking, but… whatever.
[02:58] inimino: elliottcable: air-conducting, is that conducting without a ... baton?
[02:58] elliottcable: inimino: yes. yes it is.
[02:58] Bluebie: it's the best kind!
[02:58] inimino: hehe
[02:58] Bluebie: I did it all the way home last night after the pub
[02:58] Biscuits: Hmmm, somewhere I feel a XML parser implemented in JS would be neater :p
[02:59] Bluebie: what with The Cinematic Orchestra on the ipod and all
[02:59] inimino: haha
[02:59] inimino: Biscuits: are you volunteering to write one? :)
[02:59] elliottcable: (check['constructor'] = function (blueprint) { … }).prototype = check;
[02:59] elliottcable: fuck yes that’s some awesome code.
[02:59] Bluebie: best thing about walking home at midnight is acting weird with no consequence in public spaces :D
[03:00] inimino: 
ACTION notes that XML parsing is Really Hard™

[03:00] Biscuits: inimino: I could probably create something quick and dirty
[03:00] Biscuits: Nah, it's not
[03:00] inimino: elliottcable: Crockford would not and I do approve
[03:00] Bluebie: is it?
[03:00] Bluebie: it looks easy
[03:00] Bluebie: how's xml hard?
[03:00] inimino: Biscuits: if you don't do a half-assed job it actually really truly is
[03:01] elliottcable: inimino: what?
[03:01] inimino: Bluebie: well, you know DTDs?
[03:01] Biscuits: inimino: How exactly do you feel it's hard ?
[03:01] Biscuits: Ah, yeah, ok, DTDs are a pain :p
[03:01] Bluebie: why would you want to parse a dtd? dtd's aren't xml, they're dtd's.
[03:02] Biscuits: but something similar to TinyXML should be relatively easy
[03:02] Bluebie: and.. I still have no idea when a dtd is useful for anything but validation, which is something we aaaaaalready have a bazillion tools to do, we don't need another
[03:02] inimino: 
ACTION rests case

[03:02] inimino: Bluebie: actually, they can appear in XML documents
[03:02] Bluebie: just something to parse strictly valid xml and ignore doctypes <_<
[03:02] Bluebie: yes, I've seen inline dtd's
[03:03] inimino: Bluebie: you mean "not an XML parser"
[03:03] Bluebie: okay
[03:03] Bluebie: that's what I mean
[03:03] Bluebie: a thing for parsing most of the xml that ever happens and not the insane stuff, should be really easy
[03:04] elliottcable: inimino: ugh
[03:04] elliottcable: everybody, just get this out of the way: Bluebie is not one of us. She…
[03:04] inimino: well yes, if you do a "parser for the subset of XML you care about" then it can be pretty easy
[03:04] elliottcable: she only cares about making stuff good enough for it to work some of the time. *looks away, ashamed*
[03:04] elliottcable: inimino: leave it, I’ve spent *days* on arguments like this with her. Seriously.
[03:04] Bluebie: yep, I care about making things, not code
[03:05] Bluebie: server's a means to an end.
[03:05] inimino: hehe
[03:05] inimino: well, as long as you don't call it an XML parser I don't care what subset you parse
[03:06] Bluebie: it parses some xml, it's an xml parser
[03:06] Bluebie: itunes doesn't know what a namespace is, but they still call the parser in that an 'xml parser'
[03:06] inimino: XML parsers don't have to understand namespaces, that's a separate spec
[03:06] elliottcable: lol @ this
[03:07] inimino: and it's designed specifically to always be compatible with non-namespace-aware parsers
[03:07] Bluebie: And next on This Week In Semantics, we'll be discussing whitespace readability enhanced strictly invalid JSON, and what to call it!
[03:08] elliottcable: >_<
[03:08] inimino: the trouble with XML is people think "oh, it's so easy, so great" and gets all this good marketing for being easy mostly because people have no idea what's actually required
[03:08] Bluebie: Later today: An interview with richard stallman, on what he thinks we should call linux!
[03:08] elliottcable: I think inimino is a pretty cool guy. Eh gets in arguments wiht Bluebie and dosent back down
[03:09] Bluebie: inimino: I know how terrible xml can be, it's why I personally never use it for anything ever, unless having to interface with some daft XML api
[03:09] inimino: (and yes, most of what's in the spec *actually is* required if you are doing "serious stuff" with XML, and people will complain about your stuff if it doesn't)
[03:10] Bluebie: (people will complain about everything, always, for it is humanity's greatest skill)
[03:10] inimino: so in summary and in conclusion, XML is hard
[03:11] Bluebie: or easy, depending on everything.
[03:11] elliottcable: 
ACTION sighs, puts on some Béla Viktor János Bartók, and gives up on getting anything useful out of this channel right now

[03:11] elliottcable: 
ACTION airconducts erratically

[03:12] elliottcable: airconducting to Bartók is like having a freaking seizure
[03:12] inimino: hm, Bartok
[03:12] inimino: good taste
[03:13] elliottcable: good taste? #awesome taste.
[03:13] inimino: granted
[03:13] elliottcable: it’s okay, the next thing to come on after Bartók was Taylor Swift. You don’t have to feel inferior to me.
[03:13] elliottcable: 
ACTION skips over it and looks for something that *isn’t* shit

[03:13] elliottcable: hm, Daft Punk. THat’ll do.
[03:14] inimino: I was listening to Shostakovich all afternoon, so I don't :P
[03:14] elliottcable: hah!
[03:15] inimino: never heard of Taylor Swift though
[03:15] inimino: oh, some kind of pop
[03:16] elliottcable: …
[03:16] elliottcable: what, exactly, *are* you?
[03:17] elliottcable: it’s famous for being the most horribly ‘pop-y’ of all pop.
[03:17] elliottcable: I dunno why it’s in my library o_o
[03:17] elliottcable: in flac nonetheless.
[03:17] inimino: is it new?
[03:18] Bluebie: I don't know who taylor swift is o_o
[03:18] frodenius: lol taylor swift in flac
[03:18] Bluebie: maybe it's an alaska thing
[03:18] Bluebie: alaskan pop
[03:18] elliottcable: 
ACTION shrugs

[03:18] jed has joined the channel
[03:18] SteveDekorte2 has joined the channel
[03:18] isaacs has joined the channel
[03:18] quirkey has joined the channel
[03:18] kriskowal has joined the channel
[03:18] emyller has joined the channel
[03:18] johan-s has joined the channel
[03:18] bentomas has joined the channel
[03:18] helgim_ has joined the channel
[03:18] ashb has joined the channel
[03:18] sfuentes has joined the channel
[03:18] inimino has joined the channel
[03:18] intellectronica has joined the channel
[03:18] sztanpet has joined the channel
[03:18] rudebwoy has joined the channel
[03:18] m1631_ has joined the channel
[03:22] inimino: elliottcable: so yeah, I don't hear about a lot of pop
[03:22] inimino: elliottcable: not listening to the radio probably helps
[03:22] elliottcable: haha
[03:23] elliottcable: SteveDekorte2 O_O
[03:23] elliottcable: SteveDekorte2: you’re in here? COOL
[03:23] elliottcable: this room is accumulating awesome really fast.
[03:23] SteveDekorte2: hey elliottcable :)
[03:24] SteveDekorte2: elliottcable: have you done any work with nodejs bindings?
[03:24] elliottcable: SteveDekorte2: nope!
[03:24] SteveDekorte2: are there nodejs performance benchmarks for OSX?
[03:25] elliottcable: SteveDekorte2: nope!
[03:25] elliottcable: SteveDekorte2: ask me another question ask me another question! go go go!
[03:26] SteveDekorte2: will you answer this question with a "no"?
[03:26] elliottcable: SH—
[03:26] elliottcable has left the channel
[03:26] SteveDekorte2: :)
[03:26] elliottcable has joined the channel
[03:26] elliottcable: <_<
[03:26] inimino: he exploded in a puff of logic!
[03:26] elliottcable: >_>
[03:26] elliottcable: I hate SteveDekorte2 for being smarter than me.
[03:26] elliottcable: lol
[03:27] elliottcable: 
ACTION quietly worships SteveDekorte2

[03:27] inimino: you must have so many enemies <duck>
[03:27] Bluebie: okay, time for food, cya people who like code
[03:27] elliottcable: don}t mind me, I’m just bein’ all sittin’ here, worshipin’ SteveDekorte2…
[03:27] SteveDekorte2: {blushing}
[03:27] inimino: see you, Bluebie
[03:27] SteveDekorte2: elliottcable: doing anything cool with nodejs?
[03:28] elliottcable: yes.
[03:28] elliottcable: totally.
[03:28] elliottcable: SteveDekorte2: http://github.com/elliottcable/poopy.js/blob/new-acquire/lib/acquire.js read.
[03:28] elliottcable: SteveDekorte2: gonna be the coolest package require/acquire system in the history of programming. d-:
[03:29] SteveDekorte2: elliottcable: nice :)
[03:30] elliottcable: so, lemme know when you opensource that cloning thing
[03:30] elliottcable: on that note, bbiab, I guess, time to do less talking and more hacking
[03:30] softdrink has joined the channel
[03:30] elliottcable: hahahah awesome: http://github.com/elliottcable/grizzly/commit/3c3a02cc0a68c68c0ef1b0313ea1d3fd23195dd7#L0R58
[03:34] okito has joined the channel
[03:34] elliottcable: 18% code, 78% comments. Hah!
[03:34] RayMorgan has joined the channel
[03:36] inimino: elliottcable: setComment(function, timeout)
[03:36] inimino: erm
[03:36] inimino: elliottcable: setTimeout(f, milliseconds)
[03:36] elliottcable: what?
[03:36] elliottcable: oh shit.
[03:36] elliottcable: inimino: you’re the bomb.
[03:37] elliottcable: inimino: also, holy shit, you read that much of my comments? O_O are you *high*?
[03:37] devyn has joined the channel
[03:37] elliottcable: inimino: you’re, like, awesome.
[03:37] inimino: hehe
[03:37] elliottcable: not as awesome as me, don’t get any ideas, but awesome.
[03:37] devyn: lol
[03:37] inimino: haha
[03:38] devyn: he likes to pretend he's awesome
[03:38] elliottcable: you like to pretend I’m not.
[03:38] devyn: it makes him feel more confident
[03:38] elliottcable: Makes you feel less bawwww that I turned you down.
[03:38] inimino: ooh
[03:38] devyn: Sure....?
[03:38] elliottcable: It’s okay, I’m sure somebody will love you, someday. :3
[03:39] devyn: lol
[03:39] elliottcable: lol
[03:39] inimino: 
ACTION makes popcorn

[03:39] devyn: oooh! can I have some?
[03:40] inimino: 
ACTION makes more

[03:41] devyn: lol
[03:41] devyn: I want one of those big fancy popcorn cart-machine things
[03:41] devyn: that could be dangerous beside my desk though...
[03:41] devyn: oh, and I don't think I'm allowed to eat popcorn because of my braces anyway... oh well
[03:42] devyn: 
ACTION sighs.

[03:42] inimino: 
ACTION eats extra bag himself

[03:44] elliottcable: 
ACTION looks disgusted

[03:44] elliottcable: SO GUISE IS NODE THE NEW RAILS
[03:44] elliottcable: WILL IT BEAT 42SIGNALS
[03:44] elliottcable: WILL DHH LOOK ALL SAD AND SUCK IT SADLY, WHILE BEING SAD
[03:45] elliottcable: fuck, 42signals would be so awesome.
[03:45] elliottcable: It would be like 37signals, but with 5 more signals!
[03:46] inimino: haha
[03:47] jed has left the channel
[03:47] elliottcable: hey, inimino, how would you refactor this? http://github.com/elliottcable/grizzly/blob/master/bin/teddy.js#L36-58
[03:47] elliottcable: 
ACTION is curious of your stylistic opnion

[03:47] elliottcable: I CAN’T SPEL OPNION
[03:47] edspencer has joined the channel
[03:47] elliottcable: I HEREBY REPLACE IT PERMANTELY WITH ONION
[03:48] inimino: heh
[03:49] elliottcable: inimino: gogogo
[03:49] freenode-connect: 
VERSION

[03:49] inimino: 
ACTION looks

[03:50] inimino: !typeof blueprint['target'] === 'undefined' is never true
[03:50] inimino: ! binds tighter than ===
[03:50] elliottcable: yeah
[03:50] elliottcable: balls, that bites me in the ass AGAIN
[03:51] elliottcable: how the fuck come I can never remember the !== operator!
[03:51] elliottcable: I have *never* written in a language where (!foo == bar) would work, so why the fuck do I keep tring to do it in JS?
[03:51] inimino: also...
[03:51] inimino: 
ACTION hands elliottcable a !==

[03:51] inimino: or != for that matter
[03:51] inimino: someday we may have the technology to answer that
[03:52] inimino: but that day is not yet ;)
[03:52] inimino: elliottcable: also, ; after a block creates an empty statement
[03:53] inimino: s/;/";"/
[03:53] elliottcable: inimino: yes, but I use it for the same reasons I use the bracket accessors
[03:54] inimino: just as long as you know
[03:54] elliottcable: I didn’t, thanks
[03:54] elliottcable: it can’t be that much of a performance thing.
[03:56] inimino: I doubt the performance hit is detectable
[03:56] inimino: but it's stylistically questionable IMHO
[03:58] isaacs: elliottcable: why do you use bracket accessors?
[03:59] isaacs: bar = "bar"; foo[bar]; is so much more wonky than foo.bar
[03:59] isaacs: and foo["bar"] is just extra ugly
[04:00] isaacs: imo, javascripters should make friends with jslint.  then, once it's broken you to its will, start branching out in search of beautiful terseness.
[04:00] isaacs: it's like jazz, though.  learn the conventions, so that when you violate them, you mean it.
[04:01] inimino: elliottcable promised us a writeup of his reasons for the bracket thing
[04:01] inimino: but yeah, I agree with isaacs except about JSLint
[04:02] isaacs: inimino: note: i think jslint is a good place to start, not a good place to finish.  it yells at me daily.
[04:02] isaacs: 
ACTION works on yui, so sees jslint output very very very often

[04:03] inimino: isaacs: yeah, I think JSLint has many failings, and people are better off not going down that path, better to just learn the /actual/ language directly
[04:03] inimino: (instead of somebody's idea of what are the good parts)
[04:04] isaacs: inimino: aren't you the one with that crazy no-white-space-or-semicolons-evar style, right?
[04:04] inimino: isaacs: yes, though I do actually use whitespace for indentation (sometimes quite a bit)
[04:05] isaacs: well, right
[04:05] isaacs: i'm mocking only a little.  i like terseness, too, but not compression.
[04:05] inimino: but yes, not much around operators and such
[04:06] isaacs: i go so far as to \n and indent for my chained functions.
[04:06] inimino: I like terseness and readability
[04:06] isaacs: (not again for each one, just for all the methods on a single thing)
[04:07] inimino: oh, like promises and such?
[04:07] inimino: I tend to do that
[04:10] cloudhead has joined the channel
[04:10] cloudhead: elliottcable: ping
[04:14] elliottcable: what?
[05:04] devyn: pong!
[05:04] devyn: ping, pong!
[05:04] devyn: May I propose a new "ping" protocol?
[05:05] devyn: open()
[05:05] devyn: Client (4 bytes): ping
[05:05] devyn: Server (4 bytes): pong
[05:05] devyn: close()
[05:05] devyn: does any application own port 1337?
[05:07] kriskowal: 31337 might be available :P
[05:07] voodootikigod: WASTE
[05:08] voodootikigod: back orifice
[05:08] malkomalko has joined the channel
[05:09] devyn: what's "back orifice" again? I forget.
[05:09] devyn: I've heard of it...
[05:12] bentomas has left the channel
[05:19] Biscuits: Hmmm
[05:19] Biscuits: Seem to have written a pretty decent XML library in JS now :p
[05:20] Biscuits: Not too standards compliant I suppose, but it seems to get the job done
[05:22] RayMorgan has joined the channel
[05:23] Tyllyn has joined the channel
[05:29] devyn: cool
[06:14] isaacs has joined the channel
[06:17] dschn has joined the channel
[06:28] richtaur has joined the channel
[06:28] keeto has joined the channel
[06:28] voodootikigod has joined the channel
[06:28] nefD has joined the channel
[06:28] orlandov has joined the channel
[06:28] rektide has joined the channel
[06:28] ryah_away has joined the channel
[06:45] B1scuits has joined the channel
[07:33] rakeshpai has joined the channel
[07:33] okito has joined the channel
[08:05] devyn has left the channel
[08:09] dschn has joined the channel
[08:27] rtomayko has joined the channel
[08:33] sixtus42 has joined the channel
[08:36] insertinanename has joined the channel
[08:37] insertinanename: Has anyone come across a "AttributeError: 'module' object has no attribute 'GuessOS'" error when building? (OS X 10.6.2)
[08:44] isaacs has joined the channel
[09:03] saikko has joined the channel
[09:05] johan-s has joined the channel
[09:12] gwoo_ has joined the channel
[09:30] the_undefined has joined the channel
[09:31] sfuentes has left the channel
[09:38] phidah has joined the channel
[10:30] webben has joined the channel
[10:33] keeto has joined the channel
[10:35] keeto has joined the channel
[10:39] malkomalko has joined the channel
[11:26] voodootikigod_ has joined the channel
[11:44] edspencer has joined the channel
[11:47] liefy_ has left the channel
[12:10] sixtus42: forgot a  new construction a promise
[12:10] sixtus42: V8 FATAL ERROR. v8::Object::SetInternalField() Writing internal field out of bounds
[12:10] sixtus42: is what I got
[12:10] sixtus42: now that's an easy way to terminate node
[12:13] soveran has joined the channel
[12:45] edspencer_ has joined the channel
[12:57] Connorhd has joined the channel
[12:58] Biscuits has joined the channel
[13:14] webben: Has anyone got env.js running in node?
[13:26] webben: I've found an error in the documentation for modules: var circle = require("./circle"), var sys = require("sys");
[13:26] webben:  - second var is erroneous.
[13:28] jan____: yeah, I think there's supposed to be a ; instead of the ,
[13:32] Micheil has joined the channel
[13:33] Micheil: hey, does Node.js have a daemonization feature?
[13:34] harryv has joined the channel
[13:34] Micheil: I'm assuming yes, due to the process.pid API
[13:36] ashb: i thought env.js uses lots of java classes?
[13:37] webben: ashb: I'm not sure. I don't think so.
[13:38] ashb: might not now
[13:38] ashb: it used to
[13:41] webben: really? I thought it was intended as a pure JS implementation
[13:41] sixtus42 has joined the channel
[13:42] ashb: thats no thow i read it
[13:44] ashb: well some parts have to be - the XHR for instance can't be done in pure JS surely?
[13:44] Micheil: it'd probably be just an interface to C
[13:45] ashb: given it initally ran on rhino only, no it wouldn't be C
[13:45] webben: good point
[13:45] Micheil: (just like firefox's XMLHttpRequest is an interface to C++ (via mozilla xpcom))
[13:46] ashb: http://github.com/thatcher/env-js/blob/master/src/platform/rhino.js
[13:46] webben: 
ACTION is now confused what "platform-agnostic" vs. "Rhino-specific" means at http://github.com/thatcher/env-js

[13:46] ashb: seems to be reasonably well abstracted - that is the only platform specifics i can find
[13:47] ashb: dist/env.js is pure JS
[13:47] webben: maybe "Rhino-specific" means their modified version of rhino rather than a generic version of rhino?
[13:47] ashb: dist/env.rhino.js is the only rhino specific parts
[13:47] ashb: w/ 26
[13:48] Micheil: umm.. https://gist.github.com/9dad43245c92190d033d
[13:48] Micheil: any ideas on that?
[13:49] ashb: none what so ever
[13:51] rakeshpai has joined the channel
[13:52] Micheil: can I run node as a daemon?
[13:52] ashb: 'node foo &'? ;)
[13:53] edspencer has joined the channel
[13:53] Micheil: hmm.. not really what I was after, more something that gave the node instance a pid and such, like a proper webserver
[13:57] webben: 
ACTION fails to get env.js running as a module. I guess the thing to do might be to split up bits of this giant env.js file into individual CommonJS modules.

[13:59] Micheil: because that daemonization is currently the only thing holding me back from using node to build a rather large-ish site.. 
[13:59] webben: ah, i see it's already using hsvionen's html5parser
[13:59] johan-s: Micheil: fork() is only exposed via the createChildProcess()
[14:00] johan-s: Micheil: been meaning to write a patch for that, but always get distracted
[14:00] Micheil: johan-s: hmm?
[14:00] Micheil: johan-s: I'm meaning a daemon as in it places a pidfile into something like /var/run/nodejs.pid
[14:01] Micheil: is that what you're implying?
[14:01] johan-s: Michell: yes, for which you'd usually fork ;)
[14:01] Micheil: okay
[14:01] Micheil: johan-s: Any help would be appreciated here :)
[14:04] Micheil: johan-s: the reason I'm looking for this daemonization is because a lot of the servers / services that are running on my server are being monitored by monit, which requires a pid file iirc.
[14:05] johan-s: Micheil: there's no daemonize() or similar in node yet, you'd have to write the pidfile yourself and spawn/background it from some other process
[14:05] Micheil: okay
[14:07] Micheil: hmm.. looks' like I've got a lot to work on over the summer holidays then :D
[14:19] brandon_beacher has joined the channel
[14:19] Micheil: johan-s: My feeble attempt: http://gist.github.com/242732
[14:19] harryv has left the channel
[14:20] n8o has joined the channel
[14:25] dschn has joined the channel
[14:25] edspencer_ has joined the channel
[14:30] johan-s: I actually think libev has some functions for handling the event loop deal when forking, so should be doable. Would be fun to have a ruby-style fork: fork(function(){ #this runs in the forked child })
[14:39] n8o: looks a little like ObjC's forking
[14:39] jan____: it's all C-style forking anyway :)
[14:46] johan-s: true
[14:48] Micheil: johan-s: right now, I'm just working on bash forking
[14:48] voodootikigod has left the channel
[14:48] voodootikigod has joined the channel
[14:48] voodootikigod has left the channel
[14:50] voodootikigod has joined the channel
[14:53] Micheil: johan-s: this works better: http://gist.github.com/242732
[15:07] sixtus42 has joined the channel
[15:11] coolguy has joined the channel
[15:12] n8o has joined the channel
[15:46] nefariousD has joined the channel
[15:47] n8o has joined the channel
[15:48] the_undefined has joined the channel
[15:51] Micheil: hmm..
[15:52] the_undefined: !logs
[15:54] Connorhd: (since we should be warning people)
[15:55] gwoo: Connorhd: nice call
[15:55] Micheil: hmm..
[15:55] gwoo: Micheil: question?
[15:56] Micheil: gwoo: no, just trying to work more out on this bash powered daemon for node
[15:56] gwoo: oh nice
[15:56] nefariousD: One of the channels I frequented many years ago had an "inconvenient quote bot" which would log single lines of text from users randomly, and would occasionally bark them out into the channel.. Needless to say, they could almost always be taken *way* out of context.. Great laughs, I tell ya..
[15:57] Micheil: gwoo: yeah, I've got an earlier version up at http://gist.github.com/242732
[15:57] sztanpet: whats the "daemon" in that bash script
[15:57] Micheil: gwoo: hopefully later on node will support this natively
[15:57] sztanpet: looks like an init script
[15:58] Micheil: sztanpet: purely the fact that it's creating a pid file and forking
[15:58] Micheil: then later you could call node-server stop
[15:58] Micheil: and it'd kill that instance
[15:58] Micheil: anyway, it's 3am, night.
[15:59] gwoo: night
[15:59] gwoo: Micheil: looking gooood
[16:03] bentomas has joined the channel
[16:04] n8o_ has joined the channel
[16:05] liefy has joined the channel
[16:09] inimino: Micheil: still around?
[16:10] gwoo: inimino: too bad i think you just missed
[16:10] inimino: ah well,
[16:11] gwoo: did you have some ideas?
[16:11] inimino: was going to give him a tip about that bash script
[16:11] inimino: or he can just use mine which already works
[16:15] gwoo: oh hah
[16:15] gwoo: did you fork the gist?
[16:18] inimino: no
[16:34] frodenius: inimino: what's your code?
[16:45] inimino: frodenius: http://paste2.org/p/531906
[16:45] inimino: frodenius: the main thing I wanted to point out to Micheil was how to get the PID correctly, as his code will break if more than one node instance is running (which I do routinely)
[16:48] Atmoz has joined the channel
[16:54] _wil_ has joined the channel
[17:02] _wil_ has joined the channel
[17:03] _wil_: having trouble building on ubuntu 8.04 with the following error messages
[17:04] _wil_: http://pastie.org/private/0t8jaspjpdf13asw8fpcqa
[17:06] bentomas_test has joined the channel
[17:08] okito has joined the channel
[17:09] n8o has joined the channel
[17:10] bentomas has left the channel
[17:15] _wil_: anyone know how to resolve that?
[17:17] cadorn has joined the channel
[17:18] ashb: _wil_: apt-get install gnutls-dev or similar
[17:18] ashb: (guessing here)
[17:19] _wil_: ashb: i tried that, same message
[17:19] _wil_: thx though
[17:20] _wil_: apt-get install libgnutls-dev
[17:31] bentomas has joined the channel
[17:34] aguynamedben has joined the channel
[17:39] sixtus42 has joined the channel
[17:46] coolguy: i'm having an issue with Chrome sitting in a "loading" state while it's waiting for a response from node
[17:46] coolguy: i'm trying to take the chat example
[17:46] inimino: coolguy: you forgot resp.finish()?
[17:48] coolguy: nope, it's there
[17:48] coolguy: i'm trying to take the chat example
[17:48] coolguy: and turn it into a simple
[17:49] coolguy: sit and poll and wait for data to be pushed
[17:49] coolguy: here's my client code
[17:49] coolguy: http://pastebin.com/m4daa6601
[17:49] coolguy: server code
[17:49] coolguy: http://pastebin.com/mc53fc2
[17:49] coolguy: which uses fu.js from the chat example
[17:50] n8o: i need to start using let
[17:50] coolguy: fu.js
[17:50] coolguy: http://pastebin.com/m835511d
[17:50] coolguy: when i change the client code
[17:50] coolguy: to make a dummy request first
[17:50] coolguy: then onComplete start longPoll()
[17:50] coolguy: it works fine
[17:50] coolguy: working client: http://pastebin.com/m3bd1cc78
[17:50] inimino: 
ACTION should probably look up what this fu.js thing is

[17:51] coolguy: i'm just curious as to why the first ajax request is needed
[17:52] coolguy: inimino: fu.js is from here: http://github.com/ry/node_chat
[17:53] inimino: ah
[17:54] coolguy: alternatively, does anyone have a working example of a client that will just sit and wait for a response from the server.. and perform an action when the response is received?
[17:56] inimino: 
ACTION hasn't gotten to any comet stuff yet

[17:56] inimino: n8o: does v8 support let?
[17:56] inimino: n8o: I thought they were strictly adhering to the standard :(
[17:57] johan-s has joined the channel
[18:11] quirkey has joined the channel
[18:16] _wil_: has anyone else compiled on Ubuntu 8.04
[18:28] rtomayko has joined the channel
[18:36] cruxst has joined the channel
[18:51] n8o: inimino: works in node-repl
[18:52] n8o: actually
[18:53] n8o: that's not true - the syntax is supported but it kind of barfs on it haha
[18:53] inimino: oh
[18:53] inimino: interesting
[18:55] orlandov: _wil_: yes, i was running it in 8.10
[18:55] orlandov: er
[18:55] orlandov: nm you're looking for 8.04 :p (must learn to read one day..)
[18:56] _wil_: orlandov: thanks, actually latest in git is broken for 8.04 but it seems that 0.1.18 compiles fine
[18:56] emyller has joined the channel
[18:58] okito has joined the channel
[18:58] n8o: let may not be upported :(
[18:58] inimino: n8o: good
[19:00] n8o: inimino: why good? i prefer the mozilla JS spec to EMCA
[19:00] inimino: n8o: I don't, when things are likely to change before being standardized
[19:01] n8o: "the standard" is relative with JS/emca imho. emca is A standard, but not THE standard
[19:01] n8o: seems like mozilla has been doing a better job
[19:01] n8o: then there's adobe...
[19:02] inimino: n8o: every major JavaScript implementation conforms to it, I'd say that makes it THE standard for all practical purposes
[19:02] n8o: lowest common denominator
[19:03] n8o: waiting for large standards bodies is usually a losing proposition
[19:03] n8o: webkit would be quite a bit less interesting if they were still waiting for HTML 5 before adding transforms, etc
[19:03] inimino: Adobe went off and did their own thing
[19:03] inimino: interoperability counts for a lot
[19:03] inimino: I think it's great that Mozilla is still willing to experiment and put things out there, but not all of those features are fully-baked
[19:05] n8o: i started checking it out because someone on the mailing list mentioned yield
[19:06] n8o: if only it worked, it'd be a great way to do threading :S
[19:06] n8o: v8 also has mozilla getters and setters...
[19:07] inimino: yield isn't really equivalent to coroutines
[19:07] inimino: I've seen some discussion floating around about it as some kind of concurrency solution but that's a red herring
[19:07] n8o: i know what you mean
[19:08] n8o: i'd love to see a GCD-like method for doing threads
[19:08] n8o: especially if they support multi processor/core
[19:08] inimino: n8o: getters and setters are in ES5
[19:08] inimino: (and the standardization process did them a lot of good)
[19:09] n8o: ES5 is just a candidate i thought
[19:09] inimino: GCD?
[19:10] n8o: grand central dispatch, snow leopards distributed processing stuff
[19:10] inimino: n8o: it's finalized, just awaiting the ECMA rubber-stamp
[19:10] inimino: ok
[19:11] n8o: GCD would work well with JS, it's based on closures which appl added to their C implementation to make it work
[19:12] inimino: ah
[19:12] inimino: workers are nice, but workers + closures would be much nicer
[19:12] inimino: unfortunately that's currently impossible as closures cannot be serialized
[19:13] n8o: yar
[19:13] inimino: yeah, something like that in JavaScript would be nice
[19:13] n8o: GCD is OO, someone with more C chops than I should hack it onto v8 for me
[19:13] inimino: though I can't see it being added to the core language anytime soon
[19:14] n8o: may not need to be in the language, might be possible to add as a node module in C ...?
[19:14] n8o: GCD is OSS rather
[19:15] inimino: maybe
[19:20] ashb has joined the channel
[19:21] sixtus42_ has joined the channel
[19:40] saikko has joined the channel
[20:01] sudoer has joined the channel
[20:08] coolguy_ has joined the channel
[20:09] ashb has joined the channel
[20:19] sudoer: are there any javascript libraries available for webcrawling like mechanize or nokogiri/hpricot for javascript?
[20:23] sudoer: where do you guys recommend to see server side javascript libraries?
[21:01] webben has joined the channel
[21:07] sztanphet has joined the channel
[21:24] Micheil: inimino: ah, true
[21:24] webben has joined the channel
[21:25] Micheil: inimino: node httpd.js >log/$(date +%Y%m%d) 2>&1 &
[21:25] Micheil: shouldn't that be:
[21:25] Micheil: node httpd.js >>log/$(date +%Y%m%d) 2>>&1 &
[21:25] Micheil: ?
[21:25] inimino: Micheil: half right
[21:25] Micheil: inimino: I think it's an area that needs more exploring
[21:26] Micheil: the pure reason I needed the pid was to monitor it using something like monit or god
[21:26] inimino: you don't need the second >> I think
[21:26] inimino: Micheil: however, it's the way it is because my server crashes a lot and I actually don't want all the logs, just the most recent one
[21:26] inimino: but yes, >>log/... in most cases would be what you want
[21:27] Micheil: I don't honestly understand how that script works atm
[21:27] Micheil: (I don't do a lot of bash scripting)
[21:28] inimino: the curl stuff is also specific to my setup
[21:28] inimino: all you probably want are the three lines that start the file and get the PID and write it out to some file
[21:29] Micheil: which line / where do you get the PID in yours?
[21:29] inimino: then I have another script that kills it based on whatever is in that file
[21:29] inimino: (and you probably want a more traditional init.d-style script, and for the pidfile to be in /var/run/ and so on)
[21:30] Micheil: inimino: currently I'm just getting it working using /tmp/ or something
[21:30] inimino: Micheil: I don't remember the line number but it's the one that looks like "PID=$!" 
[21:30] Micheil: okay, 5
[21:34] Micheil: I'll probably rewrite mine using python or ruby or something.
[21:35] aguynamedben1 has joined the channel
[21:48] emyller has joined the channel
[21:52] JimBastard has joined the channel
[21:53] soveran has joined the channel
[22:05] n8o_ has joined the channel
[22:25] webben has joined the channel
[22:40] inimino: the most interesting thing I learned about bash recently was that if you execute a shell script which writes to its own file, the new file will be used starting with the subsequent line of the script
[22:55] sudoer: inimino: nice
[22:56] inimino: kind of a crazy feature, though it was useful in my case
[23:07] sudoer: can I use jquery and node js together?
[23:07] inimino: ew, jQuery
[23:07] inimino: probably not, jQuery is fairly reliant on browser features
[23:08] edspencer has joined the channel
[23:08] inimino: (also, what would you use it for?)
[23:08] sudoer: hmm, what would you recommend I use to parse a webpage so I can submit a form on it?
[23:09] inimino: ah, well, good question
[23:09] sudoer: I am writing an ajax proxy with node.js
[23:09] gwoo: what about env.js?
[23:09] inimino: but certainly not jQuery, what you need is really a browser
[23:09] inimino: ah
[23:09] gwoo: would that help jquery?
[23:09] inimino: jQuery isn't going to be any part of the answer to this, but env.js might
[23:10] sudoer: if I could feed a doc into jquery, I could do it
[23:10] inimino: I don't think it's going to be very easy to get that up and running though, and you'll still need an HTML parser
[23:10] inimino: 
ACTION doesn't have any easy suggestions

[23:10] sudoer: hmm, too bad :(
[23:10] inimino: uh
[23:11] sudoer: I guess I could just do it in ruby for now and rewrite it later
[23:11] inimino: jQuery is just a thin layer of syntax over the browser's native capabilities
[23:11] inimino: what you're feeding that HTML form into is a browser, and that's exactly what you don't have on the server
[23:12] sudoer: hmm, john resig shows an example of  screen scraping with jquery and env.js here: http://ejohn.org/blog/bringing-the-browser-to-the-server/
[23:12] inimino: which is, in the case of Firefox, tens or hundreds of thousands of lines of C++
[23:12] inimino: probably using his pure JavaScript HTML parser
[23:13] sudoer: hm, so it sounds like node.js doesnt really have a place here
[23:13] inimino: maybe that's part of env.js
[23:13] inimino: anyway, you could try that, you'll probably still have to write all the form submission logic yourself, and get env.js running in node...
[23:13] inimino: ruby is probably a better choice until someone ports an HTML parser to node and some more HTML-related infrastructure
[23:15] JimBastard: meeh im still working on the debugger
[23:15] JimBastard: i people like black, im reskinning it
[23:16] JimBastard: i hope*
[23:16] inimino: Henry Ford memorial edition
[23:30] webben: sudoer: I've been looking (not very hard) at trying to get the HTML5 parser working with node.js.
[23:30] sudoer: which html5 parser?
[23:30] inimino: the Python one?
[23:30] webben: sudoer: hsivonen's Java parser cross-compiled with GWT (yuck)
[23:30] inimino: hsivonen's one?
[23:31] inimino: oh, god, ugly
[23:31] inimino: what about the Firefox one
[23:32] webben: sudoer: An alternate approach might be to set up a selenium/webdriver RC instance, and use node.js's http stuff to make REST calls to that webservice.
[23:32] webben: inimino: what the one that's bound up with Gecko's codebase? that sounds even more frightening.
[23:33] webben: there is a C html5 parser in html5lib, but it looks like it's barely been touched in a year.
[23:33] inimino: webben: yes, that one, well, perhaps it would be, but... probably not too bad
[23:33] inimino: webben: easier than starting from scratch
[23:33] inimino: yeah, that's never been workable
[23:39] Connorhd has joined the channel