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

2010-01-18:

[2:20] <hassox> lads
[2:21] <hassox> anyone here?
[2:21] <hassox> I need some info on packages
[2:22] <hassox> specifically... if I have a package... it's got a lib dir containing the js for the package
[2:22] <hassox> what do I need to call the main file so I can require it?
[2:22] <hassox> require("myPackage") <-- loads what file from lib?
[3:22] <hassox> hey guys
[3:22] <hassox> any takers on my package question?
[4:08] <wycats> hey guys
[4:08] <wycats> got a question about the package format
[4:26] <hassox> hey wycats
[4:26] <hassox> me first...
[4:26] <hassox> :P
[4:27] <wycats> :P
[4:28] <hassox> I've been trying to find out what the file is called under the "lib" dir or how to specify what it's called
[4:33] <wycats> hassox: CommonJS packages is missing some stuff
[4:33] <wycats> :P
[5:06] <isaacs> hassox: if you care about npm (nonstandard cowboy coding experiment that it may be) use the "main" field for that.
[5:06] <isaacs> { name : "foo", lib : "lib", main : "lib/foo" }
[5:07] <isaacs> then require("foo") gives you the same thing as require("path/to/package/folder/lib/foo")
[5:11] <hassox> isaacs: yeah I looked at npm and sherpa...
[5:12] <hassox> just trying to understand all the diff setups atm
[5:12] <isaacs> hopefully they won't be too different for too much longer.
[5:17] <isaacs> speaking of which, that reminds me. (sends "main" field proposal to commonjs)
[5:53] <jmerlin> so in modules, i don't think wrapping them in an anonymous function works
[5:53] <jmerlin> i mean it DOES, but every function defined at the function level scope there generates a closure
[5:54] <jmerlin> and while that simulates a global scope like is desired, it's also probably computationally less efficient than would be otherwise
[5:58] <wycats> isaacs: still around?
[6:09] <wycats> damn got disconnected
[6:09] <wycats> did anyone respond?
[6:09] <jmerlin> no
[6:39] <wycats> oh well
[6:39] <wycats> jmerlin: I posted to the list about what I wanted to say
[6:39] <wycats> I think we should have an x key
[6:39] <wycats> in packages
[6:51] <hassox> wycats: an x key being a "add whatever you like here" key?
[6:51] <hassox> or x key as in x-foo : "hey"
[6:52] <wycats> yeah
[6:52] <wycats> possibly just x.foo
[6:52] <wycats> i.e. put whatever you want under x
[6:52] <hassox> yeah
[6:52] <hassox> gotcha
[7:09] <isaacs> wycats: i'm here
[7:09] <isaacs> what's up?
[7:10] <wycats> isaacs: wanted to get your thoughts on an x.* key
[7:10] <isaacs> key on what exactly?
[7:15] <wycats> on CommonJS Package specifications
[7:19] <isaacs> wycats: i'd much rather we not decide on a single "extra stuff" key. that must moves the namespace collisions to another area.
[7:20] <isaacs> better to say that you namespace your stuff under a prefix for a given package manager or something.
[7:20] <isaacs> i'd be fine with "npmMain" as my key name than "main"
[7:20] <isaacs> or even an "npm" member which npm is to merge into the main package.json object, actually, that'd be way better.
[7:20] <wycats> isaacs: I'm worried about the validation people are talking about
[7:20] <wycats> which could prevent me from adding an npm member key P
[7:20] <wycats> :P
[7:21] <isaacs> validation is for xml nerds and java programmers.
[7:21] <wycats> isaacs: this is what happened with Rubygems
[7:21] <isaacs> yeah, lame sauce.
[7:21] <isaacs> btw, what other programs are there using package.json other thna tusk in the wild today?
[7:21] <wycats> (btw: I'm knee-deep in Rubygems working on a ton of improvements, so my thoughts are cautionary tales that come from working on that)
[7:22] <wycats> isaacs: jQuery plugin repo
[7:22] <isaacs> i see
[7:22] <wycats> jQuery plugins are all CommonJS packages
[7:22] <wycats> (I also work on jQuery ;) )
[7:22] <isaacs> nice
[7:22] <wycats> isaacs: thoughts on optional dependencies?
[7:22] <isaacs> meh.
[7:22] <isaacs> yui has some sophisticated stuff around that
[7:22] <wycats> isaacs: ok... more tales from the future
[7:23] <isaacs> you tell it whether or not to load optionals, and you tell it your optionals you'd like.
[7:23] <wycats> namely rubygems
[7:23] <wycats> let me tell you the use-case
[7:23] <isaacs> kk
[7:23] <wycats> Rails, in Ruby, wants to be able to say "I don't need JSON, but I have a module that can use it. If you provide JSON, it must be version 1.1 or higher"
[7:24] <wycats> it's basically so that dependency resolvers can make sure that there is no conflicts there
[7:24] <wycats> so if I have another dependency that depends on JSON 1.0, the resolver can bail
[7:24] <wycats> (my work on Rubygems involves writing a bundler and dependency resolver)
[7:24] <wycats> http://github.com/wycats/bundler/
[7:25] <isaacs> right
[7:25] <isaacs> so you can do that with the requirements list as is, right?
[7:25] <isaacs> one thing says required : [ "json-1.0" ] and another does required:["json-1.1"] and the installer barfs.
[7:26] <isaacs> and my "json but better" module does provides : ["json-1.2"] or something
[14:50] <micheil> hey, does commonjs define setTimeout / setInterval?
[14:51] <micheil> yes, in reactor
[14:55] <ondras> no ratified proposal for that exists
[14:57] <micheil> hmm..
[14:58] <micheil> I've just noted that node.js doesn't implement the params for setTimeout and setInterval, so I started to hack to add them (based of browse style spec)
[14:58] <ondras> which params?
[14:58] <ondras> the delay in which callbacks are called?
[14:58] <micheil> I guess the only difference between the browse setTimeout and the commonjs on is the optional scope/context
[14:59] <micheil> setTimeout(func, delay, ...params)
[14:59] <ondras> well
[14:59] <micheil> vs setTimeout(func, delay, context, ...params)
[15:00] <ondras> I don't see the context mentioned in https://developer.mozilla.org/en/DOM/window.setTimeout
[15:00] <micheil> (the way I've just redone the timers in node.js, they theoretically could take a context, which is what I'm using params for, funnily enough
[15:00] <ondras> but I suppose
[15:00] <micheil> context isn't in the browser implementation
[15:00] <ondras> that you should use a closure here
[15:00] <ashb> micheil: the ...params is a FF extension i think
[15:01] <micheil> hmm.. I just found it in the html5 spec, not sure about older specs though
[15:01] * ondras believes that it is new in html5
[15:01] <ondras> no params in older specs
[15:01] <ondras> old-school closures for everyone!
[15:01] <ondras> (there are no params in event handlers, there will be no params in settimeouts!)
[15:02] <micheil> :(
[15:02] <micheil> oh well.
[15:03] <ondras> and there are no params in xhr as well .)
[15:06] <micheil> ha fail. trying to receive data from a socket with the socket not open.
[15:06] <micheil> time to find a network port..
[15:06] <micheil> bbl
[15:46] <micheil> hey, how was working on kiwi and npm?
[15:46] <micheil> ** who
[15:46] <ashb> npm = isaacs
[15:47] <ashb> not sure about kiwi - haven't heard of that
[15:48] <micheil> it's on the module's list page
[15:48] <ashb> which page?
[15:49] <micheil> http://github.com/ry/node/wiki/modules
[15:49] <ashb> try asking in #node.js then
[15:50] <micheil> oh shit
[15:50] <micheil> sorry, I thought I was in node.js.. urgh.. it's late.
[15:50] <ashb> :)
[18:06] <Wes--> ondras: hybrid modules -- that's good news -- they really do make your life easier in the long run. :)
[18:06] <Laurian> Hi, just wondering, can I use CommonJS on the client side?
[18:07] <Wes--> there's no reason why you couldn't, it was designed for that
[18:07] <ashb> hmm I want to load some module relative to aother module that isn't the current (but i've got the module object from)
[18:07] <ashb> thought on how i should do it?
[18:07] <Wes--> ashb: that's an interesting question
[18:08] <Wes--> ashb: you could do it "quickly" with exports=require in the "other" module
[18:08] <Wes--> require("other").require("./relative")
[18:08] <Wes--> ashb: you could do it "quickly" with exports.require=require in the "other" module
[18:08] <ashb> without changing the other module ideally :)
[18:08] <Wes--> that's much trickier, AFAICT there is no specified way to be able to accomplish this
[18:08] <ashb> indeed
[18:09] <ashb> i'll ask the list and see what suggestions people have
[18:09] <micheil> hmm... are there any client side commonjs compatible loaders?
[18:09] <ashb> micheil: there are a few floating arround
[18:09] <micheil> okay
[18:18] <ashb> Wes--: sent
[19:15] <Dantman> ashb, propose a require.remote?
[19:17] <Dantman> Hmm... if you had module, and a require.remote, module specific require could be implemented as require(id) { return require.remote(module.id, id); }; with the extra methods on the real require() tacked onto it.
[19:18] <Dantman> ^_^ Looks like I got more js parts for my implementation
[19:18] <Dantman> Heh, I might even be able to have some fun with __noSuchMethod__
[19:20] <Dantman> (function(realRequire, module) { function require(id) { require.remote(module.id, id); }; require.__noSuchMethod__ = function(m) { if ( m in realRequire ) ...
[19:45] <ondras> Wes--: yeah, exactly. so binary/b is now on my todo, although it will probably take some time - I really have little time for v8cgi now :/
[19:50] <jmerlin> ondras: did you see what i said about anon functions?
[19:54] <ondras> jmerlin: probably not
[19:55] <jmerlin> i don't think they're a particularly good solution to the module system
[19:55] <jmerlin> they do work in a sense, they don't prevent global dirtying via non-var variables, but they also cause every function in the module to create a closure
[19:55] <ondras> if you have a better solution, I would be glad to accept your patch :)
[19:55] <jmerlin> i'm not sure if that's desired or if it harms performance
[19:56] <ondras> but I have not other solution available for v8 now, nor am I aware of any
[19:56] <ondras> *no other
[19:56] <jmerlin> you can't change the global object in t he context on the fly?
[19:57] <ondras> as far as I know, no
[19:57] <jmerlin> im going to look into the internals, i think it should be quite simple but the google devs didn't nor should they have been required to think of everything someone would ever want to do with contexts :p
[19:58] <jmerlin> for instance, something really cool they COULD have added is host-level operator overloading, maybe in the future if someone patches it or suggests it ^^
[19:58] <ondras> good luck
[19:59] <ondras> and feel free to branch v8cgi and experiment with it..
[21:15] <Wes--> jmerlin: changing the global object in the context on the fly is a non-trivial problem
[21:15] <Wes--> jmerlin: it affects symbol and property resolution for every single object in the program
[21:19] <jmerlin> hm
[21:56] <Dantman> Wes-, I'm setting up our server in a way that I'm going to have to assign various ports for various client http or fastcgi processes by script... 61000 is my highest ephemeral port, do you think it would be a good idea to use 61001+ for local client servers?
[21:57] <Wes-> Dantman: don't see why not, as long as you stay < 65520 (?)
[21:58] <ashb> i typically use ports on the 10000 range
[21:59] <ashb> The IANA suggests 49152 to 65535 as "dynamic and/or private ports."
[21:59] <Wes-> Oh, and 61001 might be a problem if you have more than 1,000 video cards
[21:59] <Dantman> ashb, since 10000-12011 is unallocated for anything I expect
[21:59] <ashb> i'm just checking that
[22:00] <ashb> okay so ther are sone IANA things
[22:00] <MisterN> i usually use the first number that doesn't result in an error :D
[22:00] <ashb> but nothing i'll ever care about
[22:00] <Wes-> which might actually happen in an insane sunray environemnt
[22:00] <Dantman> MisterN, heh
[22:00] <MisterN> means that for some windows stuff i've used port 666
[22:00] <Dantman> lol
[22:00] <Wes-> I like to use 143 and 139 on windows
[22:00] <Wes-> just to mess with people
[22:00] <ashb> aren't those samba?
[22:00] <Wes-> :>
[22:02] <Dantman> Wes-, 65520 as opposed do 65535?
[22:03] <Wes-> Dantman: Yeah, ISTR top ports were reserved for something. Long ago.
[22:03] <Wes-> Or maybe that is the top address usable by the VIC-II chip?
[22:03] <Dantman> Heh
[22:03] <ashb> The Dynamic and/or Private Ports are those from 49152 through 65535
[22:03] <ashb> is all it says now
[22:03] <Dantman> Oh well...
[22:04] <Dantman> 61000-65500 sounds good.
[22:05] <Dantman> ^_^ I'll probably run out of spare memory on that box before we run out of ports
[22:34] <Dantman> Sweet... I can use unix sockets to connect the nginx+php portions of the server... ;) I don't need as many ports, and it's easier to configure.
[22:35] <Dantman> ;) And it's supposed to perform better
[22:49] <MisterN> Dantman: yeah unix sockets are the sweetness
[22:52] <Dantman> :/ now if only I could find some coherent documentation on nginx, unix sockets, and php-cgi...
[22:52] <Dantman> You know, there is no man page for php-cgi, it just redirects to the one for php-cli
[22:52] <Dantman> The only thing I don't get yet from looking at incoherent documents, is how to create a unix socket
[22:55] <Dantman> Now to use sudo to make root install god... *snicker*
[23:02] <MisterN> Dantman: the easiest way to create a unix socket from C is perhaps socketpair
[23:02] <Dantman> bash
[23:03] <MisterN> Dantman: socat maybe?
[23:05] <MisterN> ("socat" is a useful program)
[23:13] <tlrobinson> anyone else here besides ryah and isaacs in SF / Silicon Valley? kris kowal and i are organizing a server-side js meetup sometime next week
[23:35] <cpojer> tlrobinson: is @tolmasky on irc?
[23:35] <tlrobinson> cpojer: he's traveling today
[23:35] <tlrobinson> but he's usually in #cappuccino
[23:36] <cpojer> thank you :9
[23:36] <cpojer> *:)

 

 

Logs by date :