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

2011-02-23:

[21:00] <cadorn> Wes: you around?
[21:01] <cadorn> Wes-: ^
[21:01] <Wes-> cadorn: Sort of :)
[21:02] <cadorn> Wes-: Whenever you have a few minutes ... I cleaned up the package and mappings support for BravoJS and have a commit ready for HG
[21:02] <cadorn> not sure how I should get the changes to you for review
[21:03] <Wes-> cadorn: If the changes are small, 'hg diff' is probably enough for me to read: if they're big, hg diff with a bit of an explanation about what's going on :)
[21:03] <Wes-> cadorn: The big things I'm looking for are
[21:04] <Wes-> - package plugin able to work without referencing bravojs namespace
[21:04] <Wes-> - bravojs does not get functionality not in spec
[21:04] <Wes-> #2 means, essentially, that necessary funtionality needs to be incorporated into the spec
[21:04] <cadorn> right
[21:05] <cadorn> I think I am pretty close
[21:05] <cadorn> what is left needs to be discussed
[21:05] <Wes-> that's excellent
[21:05] <Wes-> I think it will be really beneficial if the community has a way to extend CommonJS without requiring every implementor to write their own version of the extension
[21:05] <Wes-> just like the bad old days, when each browser had it's own plug-in
[21:05] <cadorn> yeah
[21:06] <cadorn> can I push to a branch on the bravojs project?
[21:06] <cadorn> the diff on bravo.js is relatively small, but there are new test files etc...
[21:06] <Wes-> cadorn: That's an excellent question: Google code has a mis-feature that causes the "active" branch to be the last branch pushed to
[21:07] <Wes-> For this reason, I've basically avoided branching on there, and prefer parallel clones
[21:07] <Wes-> (since they are really easy to merge when the time comes!)
[21:07] <Wes-> What do you think about doing a google code clone, and I put a link on the BravoJS main page to it?
[21:08] <cadorn> ok
[21:08] <Wes-> Then when I have some spare time (crunch time here ATM, unfortunately) I can review and merge. ON the plus side, I have no intention of doing /any/ work on BravoJS until I have gone through your changes
[21:09] <cadorn> ok, np, this was a lot of work to refactor and implement after all
[21:09] <cadorn> I think we can improve it still, but I need feedback
[21:09] <cadorn> I also made it work on the server
[21:09] <cadorn> will ping you when I have comitted to the cloned project
[21:09] <Wes-> Yeah - I'm definitely pleased this work is being done, it gives me great hope. Also good that somebody who knows packages is doing it - that is a weak spot in my CommonJS-foo
[21:10] <Wes-> I really believe that trial-implementation-based spec-writing has a lot of hope
[21:10] <Wes-> similar to how moz previews features for TC-39, I think it helps for a much higher quality spec
[21:10] <cadorn> yeah, I am actually building a tool to help with the process
[21:11] <Wes-> FWIW - I am running BravoJS "live" in production code these days and doing active development with it (just not ON it) -- and we are using Modules/2.0 modules in GPSEE as well so that we can share client/server modules
[21:11] <Wes-> I'm pleased with how it's going so far
[21:12] <Wes-> mixing and matching /1.1.1 and /2.0 has been smooth sailing, too
[21:12] <Wes-> (on the server)
[21:12] <Wes-> BTW, do you know if git supports sub-repositories?
[21:12] <cadorn> yeah, I am about to use it for my production stuff within a firefox extension
[21:12] <Wes-> That's how I am pulling BravoJS into my web projects, I make the google code BravoJS repo a sub-repo of the web project
[21:13] <Wes-> nice!'
[21:13] <cadorn> and on server
[21:13] <cadorn> would be great if you could add GPSEE support to PINF: https://github.com/pinf/loader-js
[21:13] <cadorn> git can do submodules yes
[21:14] <cadorn> but the approach I am taking with PINF will make that obsolete
[21:16] <Wes-> cadorn: It's certainly tempting. 1) how much non-CommonJS does it use, and 2) does it load modules with require() ?
[21:17] <Wes-> (file-read + eval is not suitable for GPSEE)
[21:17] <cadorn> you can override whatever you need via an adapter
[21:17] <cadorn> the only non-commonJS stuff is stuff I will be proposing
[21:17] <Wes-> excellent
[21:18] <Wes-> if you're not using require() though, you must be using non-commonjs to read files though
[21:18] <cadorn> you can proxy to the require() the platform provides for native modules
[21:18] <Wes-> since, for whatever reason, we haven't got a single i/o function in CommonJS :(
[21:18] <cadorn> that is how I can mix and match pure packages/modules and nodejs code/packages for example
[21:18] <Wes-> But yeah - proxying to require() is important for us, it lets us making packages with native-language modules
[21:19] <Wes-> yeah! same idea!
[21:19] <cadorn> the adapter implements the basic file IO
[21:19] <cadorn> https://github.com/pinf/loader-js/tree/master/lib/adapter
[21:20] <cadorn> There are demos to illustrate all features
[21:20] <Wes-> okay - looks like PINF would be an easy port to GPSEE when the time comes
[21:20] <cadorn> that was the intention :)
[21:20] <Wes-> I'm *so glad* to see movement like this on the CommonJS front
[21:21] <cadorn> working on browser support now to shuttle modules via transport files
[21:22] <Wes-> fwiw - there is a GPSEE (but nearly CommonJS) module in BravoJS which illustrates a possible technique for dependency resolution of /2.0 modules and aggregation for transport
[21:22] <Wes-> 'fastload' IIRC
[21:22] <cadorn> yeah, saw that

 

 

Logs by date :