Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-07-28:

[0:17] <nrstott> kriszyp, patr is looking for promised-io/sys which doesn't seem to exist...
[0:17] <nrstott> any ideas about that one?
[0:19] <nrstott> i think it should be promised-io/process
[0:19] <nrstott> yeh.. that works
[2:21] <neandrake> hello
[2:22] <neandrake> anyone awake?
[2:23] <deanlandolt1> neandrake: what up?
[2:24] <neandrake> just found commonjs and was curious what effort there has been to make js a shell scripting language
[2:26] <deanlandolt1> well, every engine has some kind of file implementation, and it seems to be coming together...you can shebang a js engine and script away
[2:27] <Wes-> neandrake: plenty
[2:27] <neandrake> what about argument passing and environment
[2:27] <Wes-> neandrake: gpsee has consume-and-yield pipelines in the shellalike module
[2:27] <Wes-> args and env are covered by everybody
[2:27] <Wes-> system spec iirc
[2:28] <neandrake> i'm mostly familiar with js as browser script, not filesystem
[2:28] <neandrake> :)
[2:31] <neandrake> so commonjs is a standard?
[2:31] <Wes-> No, more like a community trying to converge towards operability
[2:43] <nrstott> hey Wes- , how's GPSEE going
[2:43] <neandrake> is there anything similar to gpsee for v8?
[2:43] <nrstott> neandrake, try node.js
[2:43] <nrstott> but realize that the node people do things kind of their own way too ;0
[2:44] <Wes-> nrstott: It's going! "how" is hard to answer, it does everything I need it to ATM, and when it doesn't, I'll make it do more. :)
[2:44] <nrstott> I'd used promised-io from kriszyp to access the filesystem
[2:44] <nrstott> Wes-, what file system spec are you on now?
[2:44] <nrstott> Wes-, and do you have event queue?
[2:45] <Wes-> nrstott: I implemented fs-base and added some stuff so it could actually read files
[2:46] <Wes-> nrstott: event queue - haven't bothered, have some ideas, though. I DID implement node's net API in a GPSEE module, though. It's not complete, but it runs the echo server.
[2:46] <nrstott> neat
[2:47] <nrstott> you're building on spider monkey rihgt?
[2:47] <Wes-> nrstott: Yes, and I have a properitary FFI geared toward reflecting POSIX and hiding portability issues from JS
[2:47] <neandrake> nrstott, what do you mean node people do things their own way?
[2:48] <nrstott> with Spidermonkey you should be able to implement the eventquuee ontop of setTimeout right?
[2:48] <nrstott> neandrake, exactly what I said :) they dont care much about commonjs
[2:48] <neandrake> hmm
[2:48] <nrstott> narwhal will run on V8 too .. somewhat
[2:48] <neandrake> that the only v8 project similarly related?
[2:48] <nrstott> neandrake, you can do things the commonjs way on node... i recommend it
[2:49] <nrstott> use 'nodules' and 'promised-io'
[2:49] <Wes-> nrstott: Spidermonkey doesn't include setTimeout, that's part of the browser object model. But doing setTimeout etc should be easy. I actually outlined a proposal for that a couple of days ago.
[2:49] <nrstott> and kriskowal has "narwhal-node" if you want extra credit :)
[2:50] <Wes-> I bet narwhal-node would run on gpsee with a bit of work :)
[2:50] <nrstott> hehe
[2:50] <nrstott> narwhal-node-GPSEE
[2:51] <Wes-> nrstott: http://code.google.com/p/gpsee/source/browse/modules/net/net.js -- includes a simple event system implemented in JS so that node's net api can work
[2:51] <neandrake> thanks for the tips
[2:54] <nrstott> neandrake, no problem
[2:54] <nrstott> neandrake, realy the easiest way to get started with "commonjs" is to just use narwhal (or maybe GPSEE, I don't know it so well though)
[2:54] <nrstott> later on you can move into node.js land. If you care about commonjs, node.js is a hard spot to start in
[2:56] <neandrake> well I just found out about commonjs
[2:56] <nrstott> you can do shell scripting in JS really easily using narwhal
[2:56] <mschwartz> or rhino
[2:57] <neandrake> looks like the goals it states on website agree
[2:57] <neandrake> node.js is more geared towards server-side js?
[2:57] <neandrake> err, scalable network programs
[2:58] <nrstott> the primary developers treat commonjs compliance as an afterthought. it just doesn't matter much to them.
[2:58] <nrstott> you can do things the commonjs way on node, but finding examples of it is harder than finding examples of doing it "their" way
[2:59] <deanlandolt1> nrstott: i think that's improved a lot with the promised-io package
[2:59] <deanlandolt1> it'd be nice to get that to work on more than just narwhal/rhino, node and the browser of course
[3:04] <neandrake> thanks everyone for the info, i'm heading out
[3:19] <nrstott> deanlandolt1, there still aren't enough examples :)
[3:19] <nrstott> not for the casual node user
[3:19] <deanlandolt1> yeah, that's true
[3:20] <nrstott> im having a bit of trouble right now figuring out how to use the http client :)
[3:20] <nrstott> im getting a timeout for some reason
[3:20] <deanlandolt1> oh, well, just ask :D
[3:20] <nrstott> to a url i can curl...
[3:20] <deanlandolt1> for node?
[3:20] <nrstott> also the http client doesn't wrok with my npm installation, i ahve to use nodules :)
[3:20] <nrstott> my npm installation gives an error in requiring("../engines/node/lib/http-client")
[3:20] <nrstott> don't realy know how to fix that so it works for people using npm
[3:20] <deanlandolt1> oh, yeah...
[3:20] <deanlandolt1> you're on old code i guess
[3:20] <nrstott> nope im up to date :)
[3:21] <nrstott> i git merged with zyp about 3 hours ago
[3:21] <deanlandolt1> hmm, it should be trying to require ../../../engines...
[3:21] <nrstott> that's not whats currently in zyps repo
[3:21] <deanlandolt1> before or after he synced with my code?
[3:21] <nrstott> after he claimed to have
[3:22] <nrstott> http://github.com/kriszyp/promised-io/blob/master/lib/http-client.js#L6
[3:23] <deanlandolt1> oh, i'm sorry, yeah, that's right
[3:23] <deanlandolt1> hmm
[3:24] <nrstott> works fine via nodules
[3:24] <nrstott> not so hot via npm
[3:24] <nrstott> i changed the package.json npm overlay to have directories entry for "engines" but it didn't help
[3:24] <nrstott> this may be a "this isn't going to work on npm" issue
[3:24] <deanlandolt1> ahh...yeah
[3:24] <deanlandolt1> does npm do "engines"?
[3:25] <nrstott> it does "directories"
[3:25] <nrstott> you can tell it where to look for files basically
[3:25] <deanlandolt1> true, should do relative requires
[3:25] <nrstott> you do like "directories": { "lib": "./lib", "engines": "./engines" }
[3:25] <nrstott> but "engines" has no special meaning
[3:26] <deanlandolt1> gotcha
[3:26] <kriszyp> it might be conceivable to use npm's directories thing to do engine specific stuff though
[3:27] <nrstott> yeah i think it should be
[3:32] <nrstott> i think your require has to be like "promised-io/node/lib/http-client" for npm
[3:33] <nrstott> ill have to ask isaacs
[3:33] <nrstott> it would be nice if everything could work on both npm and nodules.. but that may just be impossible
[3:33] <nrstott> in npm you could do a require("nodules").ensure(....) though...
[3:34] <nrstott> kriszyp, what do you think of using nodules programatically in most spots? Seems like that would solve the issue
[3:36] <nrstott> combinign that with npms "main" could make it work
[3:36] <nrstott> you oculd have a "main" that was just for npm that just did a require("nodules").ensure...
[3:38] <nrstott> deanlandolt1, I should be able to do var HttpClient = require("promised-io").Client; new HttpClient().request({ url: "http://localhost:5984" });
[3:38] <nrstott> right?
[3:38] <nrstott> im getting a timeout...
[3:38] <nrstott> curl http://localhost:5984 is fine though
[3:39] <deanlandolt1> hmm...
[3:39] <deanlandolt1> require("promised-io/http-client").Client
[3:39] <nrstott> well yeah
[3:39] <nrstott> typo ;0
[3:39] <nrstott> im getting the client
[3:39] <deanlandolt1> well that's a start
[3:39] <nrstott> and the request is giving me a timeout, my errback is being called
[3:40] <deanlandolt1> so yeah, (new HttpClient()).request({url: "http://localhost:5984" })
[3:40] <deanlandolt1> but that shouldnt' be it
[3:41] <nrstott> yeah my promise error handle is being executed
[3:41] <nrstott> the request is firing fine.
[3:41] <nrstott> here's my actual code:
[3:42] <nrstott> var HttpClient = require("promised-io/http-client").Client;
[3:42] <deanlandolt1> what's the error?
[3:42] <nrstott> var httpClient = new HttpClient();
[3:42] <nrstott> return when(httpClient.request({
[3:42] <nrstott> url: "http://192.168.15.52:5984"
[3:42] <nrstott> }), function() {
[3:42] <nrstott> sys.puts("yo");
[3:42] <nrstott> sys.puts(arguments);
[3:42] <nrstott> }, function() { sys.puts("error", JSON.stringify(arguments)); });
[3:42] <kriszyp> if you have a way to make it work on nodules and npm, let me know
[3:42] <nrstott> {"0":{"message":"Timeout","stack":"Error: Timeout\n at Timer.callback (jar:http://github.com/kriszyp/promised-io/zipball/master!/engines/node/lib/http-client.js:68:19)\n at node.js:255:9"}}
[3:42] <deanlandolt1> for that last one do a function(e) { sys.puts(e) }
[3:42] <kriszyp> but I'm going to bed now..
[3:42] <deanlandolt1> hmm...weird
[3:43] <nrstott> curling that url works fine
[3:43] <deanlandolt1> yeah...testing it myself
[3:43] <nrstott> just using node httpclient on it works too
[3:51] <nrstott> deanlandolt1, any luck?
[3:52] <deanlandolt1> nrstott: yeah, works for me :-/
[3:53] <nrstott> ill try it vs google or something...
[3:53] <deanlandolt1> yeah, that's what i just did
[3:53] <deanlandolt1> let me try against an ip
[3:53] <nrstott> works vs www.google.com
[3:53] <nrstott> bet it does have to do with it being an ip
[3:53] <nrstott> or maybe the port
[3:53] <deanlandolt1> yeah...
[3:54] <deanlandolt1> that's the thing...url is really just a shortcut for the jsgi request obj
[3:54] <nrstott> its gotta be the port
[3:54] <nrstott> i dont see where the port is taken into account in the request
[3:54] <deanlandolt1> and node's uses the node url parser...we may have found a bug
[3:54] <deanlandolt1> crazy, Domain name not found
[3:54] <deanlandolt1> if i go against 127.0.0.1:8080
[3:55] <nrstott> deanlandolt1, i thik it has to do with our code, not nodes :)
[3:55] <nrstott> i think it should use .host instead of .hostname
[3:55] <nrstott> on line 31
[3:56] <nrstott> require("url").parse("http://192.168.0.1:5984")
[3:56] <nrstott> { href: 'http://192.168.0.1:5984'
[3:56] <nrstott> , protocol: 'http:'
[3:56] <nrstott> , slashes: true
[3:56] <nrstott> , host: '192.168.0.1:5984'
[3:56] <nrstott> , port: '5984'
[3:56] <nrstott> , hostname: '192.168.0.1'
[3:56] <nrstott> }
[3:56] <deanlandolt1> giggity
[3:57] <nrstott> thats got to be it
[3:57] <deanlandolt1> yeah, though i'm getting Domain name not found still on ips
[3:59] <nrstott> hm yeah i dont think this is the prob, that's just setting a header
[3:59] <nrstott> it looks like the call to create the httpClient is correct
[4:00] <deanlandolt1> yeah, the host/hostname distinction is just for proxies
[4:00] <nrstott> so url.parse is doing the right thing... the call to create the httpClient appears correct...
[4:01] <deanlandolt1> then why is node choking? :-/
[4:06] <nrstott> ooooh
[4:06] <nrstott> i see
[4:06] <nrstott> the call to create httpClient IS wrong
[4:06] <nrstott> it should use hostname not host as 2nd param!
[4:06] <nrstott> that's the bug
[4:07] <deanlandolt1> d'oh
[4:07] <nrstott> you going to push a fix or shall I?
[4:08] <deanlandolt1> confirmed
[4:08] <deanlandolt1> i'll push now
[4:08] <nrstott> nice
[4:09] <nrstott> this is one nice thing about nodules, now i can just switch to depend on your github dir easily :)
[4:09] <deanlandolt1> pushed
[4:09] <deanlandolt1> yeah, very nice!
[4:10] <nrstott> alright, progress!!
[4:10] <deanlandolt1> still, we need tests :-/
[4:10] <nrstott> indeed
[4:11] <nrstott> use patr :)
[4:11] <deanlandolt1> i've been struggling to find a good setup for tests in node and narwhal
[4:11] <nrstott> patr looks promsiing
[4:18] <deanlandolt1> nrstott: found a redirect bug...will be pushing another fix shortly
[4:19] <deanlandolt1> (the port gets dropped for some reason)
[4:19] <deanlandolt1> think it's related to the host/hostname issue
[4:20] <nrstott> cool
[4:22] <deanlandolt1> heyo...jack bug, nvm
[4:25] <nrstott> deanlandolt1, is response.body a promise?
[4:25] <nrstott> i mean response.body.forEach
[4:25] <deanlandolt1> response.body.forEach returns a promise, yes
[4:25] <nrstott> and are the individaul elements of it rpomises as wel?
[4:25] <deanlandolt1> all that does is signal when it's done
[4:25] <deanlandolt1> no, they're (supposed to be) objects with a toByteString on them
[4:26] <nrstott> ok
[4:26] <nrstott> this is wokring, tell me if htis looks proper
[4:26] <deanlandolt1> looks like they're just buffers though
[4:26] <nrstott> CouchClient.prototype.request = function(opts) {
[4:26] <nrstott> opts = complete(opts, { hostname: this.host, port: this.port });
[4:26] <nrstott>
[4:26] <nrstott> return when(this.httpClient.request(opts), function success(resp) {
[4:26] <nrstott> var body = "";
[4:26] <nrstott> return when(resp.body.forEach(function(chunk) { body += chunk; }), function() { return JSON.parse(body); }, function() { console.error("error", err); });
[4:26] <nrstott> }, function error(err) { console.error("error", err) });
[4:26] <nrstott> };
[4:27] <deanlandolt1> yeah, that looks right...
[4:27] <deanlandolt1> you're doing the return when in teh right two places
[4:27] <nrstott> k cool
[4:27] <deanlandolt1> that's the only real tricky part about it
[4:27] <nrstott> it seems to be working
[4:28] <nrstott> I can see why node people think this is hacky :)
[4:28] <nrstott> but once you get used to it, using forEach like this makes sense
[4:28] <deanlandolt1> we could probably sugar it up
[4:28] <deanlandolt1> sure...and actually, you can use more than forEAch
[4:29] <deanlandolt1> node's http-client returns a LazyArray...which means you can use map, reduce, filter, some, whatever you want
[4:29] <deanlandolt1> but forEach is probably the best bet
[4:30] <nrstott> hm, reduce would be more logical for what im doing of just concating strings
[4:30] <nrstott> i should use reduce
[4:30] <deanlandolt1> give it a shot
[4:31] <nrstott> i will tomorrow
[4:31] <nrstott> bout to go to bed :)
[4:31] <nrstott> thanks for the help tonight
[4:31] <deanlandolt1> also, it'll look a lot less hacky when you don't have all the error handlers in there (you can probably just let those bubble in most cases)
[4:31] <deanlandolt1> certainly...thanks for bughunting!
[4:35] <deanlandolt1> ugh...it is a node http-client bug...we're clobbering the request obj w/ nodisms accidentally :-/
[14:50] <nrstott> deanlandolt, i sent you ap ull request ;0
[14:50] <nrstott> also there is a new problem! qeury string!
[14:51] <nrstott> looks like the jsgiRequest.queryString param needs to be added onto the pathInfo
[15:08] <nrstott> just pushed a fix
[15:33] <deanlandolt> sweet
[15:33] <deanlandolt> thanks nrstott
[15:49] <deanlandolt> nrstott: just merged...i'm adding you as a contributor in package.json, should i use the whiteboard-it.com address?
[15:50] <nrstott> deanlandolt, yes, nathan.stott@whiteboard-it.com
[15:50] <deanlandolt> cool
[17:47] <nrstott> kriszyp, have you considered allowing a before and after for tests in patr?
[17:47] <kriszyp> that would be great
[17:48] <kriszyp> I wrote that pretty quickly, just so i would at least have something for cross-platform testing
[17:48] <nrstott> right... im starting to use it as well
[17:48] <nrstott> cause expresso isn't suiting me
[17:48] <kriszyp> there are certainly lots of things that could be done to improve it
[17:48] <nrstott> using promises for testing makes things a lot better
[17:51] <nrstott> Promises are so great... I don't get why the node community so thoroughly rejects them
[18:03] <kriszyp> Node community is pretty broad, there are certainly node users using promises
[18:03] <kriszyp> I don't get why people think the node community rejects them ;)
[19:02] <nrstott> kriszyp, maybe its because of the vocal group that talks about how they "just aren't for node" :)
[21:13] <mikeal> probably because they were removed from core
[21:13] <mikeal> but they were removed soi that people can implement them in however they see fit
[21:13] <mikeal> there are differences of opinion in how promises should work and enforcing it in node is kind of limiting
[21:13] <deanlandolt> IIRC kris was thrilled about that
[21:13] <mikeal> in node core that is
[21:14] <mikeal> right, i believe kris is a fan of promises that can change the subject as it comes through the callback chain
[21:14] <mikeal> and that was intentional forbidden in the node implementation that was in core
[21:14] <deanlandolt> mikeal: no, both kris's are all about immutable promises
[21:15] <mikeal> in narwhal that aren't immutable
[21:15] <mikeal> er they
[21:15] <deanlandolt> huh?
[21:15] <deanlandolt> they should be
[21:57] <Dantman> Mmmm... I can finally upgrade the wiki...
[21:57] <Dantman> eventually, that is...
[22:00] <Dantman> 1.15.4 has a CSRF vulnerability...... though I don't think that one really matters for us...
[22:02] <dguttman> Is it possible to use commonjs to run js from the command line? (i.e. using v8?)
[22:09] <Dantman> dguttman, That's already possible... the point of commonjs is to unify the apis which can be used on the different implementations
[22:09] <dguttman> awesome, i can't find out how
[22:10] <dguttman> i'd love to get into the habit of using js instead of ruby for day to day scripting
[22:10] <dguttman> but to do that i'd need a nice "$ js some_script.js" interface
[22:11] <dguttman> know how to do that?
[22:11] <Dantman> If you're just "executing js" even the spidermonkey binary can run that... what's missing is a pile of api's, js alone doesn't even have filesystem access... for that you need implementations like node.js, fluspferd, narwhal, ringo, etc... and commonjs is trying to standardize the interfaces between them
[22:12] <dguttman> exactly, that's the day-to-day scripting part
[22:12] <dguttman> where i thought commonjs came in
[22:12] <Dantman> CommonJS actually comes in after...
[22:12] <dguttman> hmm
[22:12] <Dantman> There are already a half dozen different implementations that can do things...
[22:13] <Dantman> The issue is that doing the same thing between any of them is never the same
[22:14] <Dantman> Personally I'd say /trying/ is a key though, because little of what should be a stdlib has even finished been standardized and matured by the group..... modules is the only thing that has matured so far... and es-harmony module proposals are starting to take my opinions which were tainted by require() and return them back to a similar state to my original idea...
[22:17] <dguttman> i see
[22:19] <dguttman> ok i'm starting to get it now
[22:24] <dguttman_> thanks Dantman, really appreciate the help

 

 

Logs by date :