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

2010-04-22:

[3:42] <tlrobinson_> does anyone have a commonjs module bundler that creates a self contained script out of a set of modules?
[3:55] <kriszyp> tlrobinson_, have you looked at transporter?
[3:56] <kriszyp> it resolves deps and puts them in one script
[3:56] <kriszyp> http://github.com/kriszyp/transporter
[3:56] <tlrobinson_> kriszyp: oh cool
[3:57] <tlrobinson_> is it only available as a JSGI app or can i run it as a command line tool
[3:57] <kriszyp> just a JSGI app, sorry :/
[3:58] <tlrobinson_> could i modify it to do that?
[3:58] <kriszyp> although I think you have written some mock requests stuff that could interface to it ;)
[3:58] <kriszyp> yeah, or modify it
[3:58] <kriszyp> it wraps in transport/C right now
[3:58] <kriszyp> meaning to upgrade to transport/D
[3:58] <kriszyp> don't know if you want the transport or not
[4:01] <tlrobinson_> actually i just got my super simple bundler working
[4:02] <tlrobinson_> but thanks
[4:02] <tlrobinson_> fyi http://gist.github.com/374803
[4:03] <tlrobinson_> (you have to pass it a list of modules and their paths though)
[4:44] <zaach> tlrobinson_: working with narcissus, eh?
[4:44] <tlrobinson_> zaach: yeah
[4:44] <tlrobinson_> zaach: the thing i was telling you about at jsconf
[4:44] <tlrobinson_> i told you about that, right?
[4:45] <zaach> Yes, I think so
[4:48] <tlrobinson_> the js debugger written in js, works on any platform, probably slow as shit :)
[4:48] <zaach> ah, right
[4:48] <tlrobinson_> i'll throw up a demo in a few minutes
[4:52] <zaach> I should probably finish my js parser in jison. maybe this weekend.
[4:56] <JohnnyL> Is there a way to access local files?
[4:59] <zaach> JohnnyL: only proposals
[4:59] <JohnnyL> zaach oh
[5:00] <zaach> nothing standard yet
[5:00] <JohnnyL> i suppose one could use a server.
[5:00] <JohnnyL> That is not js.
[5:00] <JohnnyL> dnuno
[5:45] <tlrobinson_> http://tlrobinson.net/xebug-demo/
[5:45] <tlrobinson_> zaach: ^
[5:46] <tlrobinson_> you kinda have to know gdb for now...
[5:58] <zaach> tlrobinson_: very cool
[13:35] <jbrantly> tlrobinson: regarding concatenating files, might want to watch http://github.com/jbrantly/yabble. It includes a (crappy) tool for wrapping modules, and it soon will support concatenation and engines besides rhino.
[16:21] <jbrantly> ping: kriszyp
[16:21] <kriszyp> hi
[16:23] <jbrantly> I had a question about Packages/Mappings. I'm pretty sure I understand, but just want to verify
[16:23] <jbrantly> each package essentially gets its own top-level module namespace, is that right?
[16:26] <kriszyp> that is not necessary, it certainly is reasonable to expect that that would be the preferred implementation approach. But package mappings allows a package to say, "I expect this module id to be resolved to this URL".
[16:26] <kriszyp> If implementations choose to give each package its own top-level namespace, great, that makes it simple
[16:26] <kriszyp> If implementations choose to have a single namespace shared by everything if makes things a little more prone to conflicts (in case the mappings collide)
[16:27] <kriszyp> but that is up to implementors (or at least beyond the scope of that little proposal)
[16:28] <kriszyp> and in the browser, where you might want a single top level namespace (to translate to url/paths back to your server), if might be better to merge mappings
[16:28] <jbrantly> alright, but, a package mapping does only apply to modules (and require()s) from within that package.
[16:29] <kriszyp> right
[16:29] <kriszyp> the mappings in my package don't dictate what the modules in your package expect for their top level namespace
[16:30] <jbrantly> right
[16:30] <jbrantly> one sec, re-reading stuff about the package root
[16:32] <jbrantly> so the comments about the package root are more for locating package.json
[16:32] <kriszyp> in my impl I support a kind of "super" mapping that the user can make locally that affects all packages/modules (in addition to their own package mapings), but that is beyond the scope of the proposal
[16:32] <kriszyp> yes
[16:32] <jbrantly> I was taking that as a way to define the top-level module namespace for the package
[16:32] <jbrantly> now it's more clear
[16:43] <jbrantly> kriszyp: any thoughts to adding versions?
[16:44] <deanlandolt> jbrantly: it already supports versions...
[16:44] <deanlandolt> just map your package to a specific commit
[16:44] <deanlandolt> or tag
[16:44] <jbrantly> yes, I get that, but I'm also trying to reconcile this to other package manager-type proposals
[16:45] <deanlandolt> kriszyp: one thing i was wondering though -- what's the deal w/ pointing to HEAD? will it check w/ the source every time you start up to see if it needs a new zip? how are the zips cached?
[16:45] <kriszyp> no, it doesn't check everytime
[16:45] <kriszyp> just downloads and uses what it has
[16:46] <kriszyp> you can delete the download files to get updates (and/or I could include a "refresh" option)
[16:46] <deanlandolt> fair enough..perhaps at some point a fn to expire a particular cache would be in order but for now you can just dump the cache
[16:46] <deanlandolt> yeah, what you said :)
[16:46] <kriszyp> yeah
[16:46] <kriszyp> indeed
[16:46] <deanlandolt> seems safer that way -- more explicit
[16:47] <kriszyp> yeah, if the user is modifying any of those packages (and we even support auto-reloading on cached files) I wouldn't want to be doing any updates on those files without being careful
[16:48] <deanlandolt> auto-reloading on cached files? you mean live?
[16:48] <deanlandolt> i thought you said that was NYI
[16:48] <deanlandolt> or is it just "reloadable" that's NYI?
[16:50] <kriszyp> well that was yesterday
[16:50] <deanlandolt> ha!
[16:50] <kriszyp> reloading works fine today
[16:50] <kriszyp> :)
[16:50] <kriszyp> yeah, hot-reloading of modules
[16:51] <kriszyp> which is really cool because it does dependency tracking, so it knows exactly what modules/factories it needs to reload/rerun
[16:51] <deanlandolt> you may want to announce on the node list...there's a lot of folks waiting for that
[16:51] <kriszyp> yes
[16:51] <kriszyp> I will
[16:51] <kriszyp> I was just shaking out some bugs today
[16:51] <kriszyp> But I think it is really in good shape now
[16:51] <kriszyp> pintura gives a good workout ;)
[16:51] <kriszyp> lots of deps
[16:52] <deanlandolt> no doubt
[16:52] <jbrantly> this is your web-modules project?
[16:52] <kriszyp> yeah
[16:52] <kriszyp> called nodules now
[16:52] <deanlandolt> oh, it's changed? i thought one depended on the other
[16:53] <deanlandolt> in any event, to get hot reloading i just futz with the projects in NODULES_PATH?
[16:53] <jbrantly> yea. I *really* want to start working on getting Yabble integrated with that (through transporter). I need to find some time
[16:54] <kriszyp> yeah
[16:54] <kriszyp> or the local one
[16:54] <kriszyp> like if you do the example wiki, you can go into the local lib directory and modify those files
[16:55] <deanlandolt> great...it's been the deps i've been modding lately -- trying to get a reasonably finished product with the binary files and the couch stuff especially
[16:56] <kriszyp> sure
[17:04] <deanlandolt> kriszyp: hmm... setting NODULES_PATH doesn't seem to be having any effect...where's the default place the cache is stored?
[17:04] <Wes__> maybe MODULES_PATH? ;)
[17:04] <kriszyp> in downloaded-modules in the current directory
[17:05] <deanlandolt> Wes__: no, nodules -- that's the name of the project :)
[17:05] <Wes__> Oh, really? dang! :)
[17:06] <deanlandolt> kriszyp: umm, yeah, that makes pretty good sense
[18:01] <deanlandolt> kriskowal: there's still one thing i'm confused by in the Q proposal -- how can it /just/ be an api question? instanceof can't be irrelevent because it's what's happening under the hood in Q.isPromise -- that means you've frozen your implementation, right?
[18:01] <deanlandolt> you can't have promises created by two competing implemenations...ever...or am i missing something?
[18:04] <deanlandolt> in any event, i'll start getting everything together for a new jsgi proposal, faq, notes, comprehensive errata, and all that good stuff
[18:43] <konobi> anyone know where that visual diagram of the commonjs require spectests is?
[19:06] <jbrantly> you talking about this? http://github.com/Gozala/graphquire
[19:11] <konobi> looks similar but is specific to the require spectests
[19:11] <jbrantly> I thought I saw that project with the require unit tests, but can't seem to find it
[19:15] <konobi> yeah, i saw a tweet with it
[19:16] <konobi> ah ha
[19:16] <konobi> http://codespeaks.com/modulr/spec_dependency_graph.html
[21:08] <kriskowal> konobi that's sweet. glad tobie did that.
[21:11] <konobi> came out 15 minutes _after_ I had gotten the commonjs module 1.0 spectests passing on the smart platform
[21:11] <konobi> yarghlq
[21:12] <kriskowal> unfortunate, but i'm glad to hear they're all passing. i'll have to write more of them for 1.1.1 just to be a thorn in the side.
[21:14] <jbrantly> kriskowal: please do. I wrote some on my own for 1.1.1, but they're not really complete I don't think.
[21:17] <konobi> similar to ashb's tests would be awesome
[21:22] <kriskowal> ashb has different tests?
[21:26] <konobi> nah... but i've seen a few different versions
[21:27] <konobi> ash's are the simpliest i've seen though
[21:29] <ashb> the interopabljs thing was just a git mirror ofthe old googlecode

 

 

Logs by date :