[0:52]<Wes-> kriskowal: what do you think of mandating require("system").print() for unit tests? [0:53]<kriskowal> i think it would be good to specify it as mandatory in general [0:53]* Wes- nods [0:53]<kriskowal> i don't feel strongly about how unit tests should be logged by default. [0:53]<Wes-> I also really like that it's mandated to use require("system").stdout -- that's a really big deal IMHO [0:54]<kriskowal> yeh. [0:54]<kriskowal> i took out narwhal's print free var. [0:54]<kriskowal> in my future branch. [0:54]<Wes-> GPSEE still has a free print, but it is distinctly different from the one in the system module [0:54]<kriskowal> but, it became impractical to live without it. i reworked the loader to inject a print again, forwarding to require("system").print [0:55]<Wes-> heh [0:55]<jbrantly> it's interesting to think about stdin/stdout/print in terms of a browser environment. I'm sure there have been discussions on it, but I'm just now starting to think about it. [0:55]<kriskowal> there hasn't been extensive discussion; i've always had it forward to console.log in my work [0:56]<Wes-> stdout could be done in a couple of diffferent ways -- document.write to another IFRAME being undiscussed but interesting [0:56]<kriskowal> actually, chiron injected "log" as a free variable, but same idea [0:56]<Wes-> similarly, appending to a textarea [0:57]<Wes-> of course, the javascript console and firebug console are also attractive targets, but those are the obvious ones. ;) [0:57]<kriskowal> yeh. i had a system set up where you could go to a console.html page like console.html?my-module.js to run a script [0:57]<kriskowal> completely static, worked even under file:/// [0:57]<kriskowal> it was awesome for dev [0:57]<Wes-> One of our web apps actually has a detailed logger that you can just "make appear" by tweaking it on with javascript booklets [0:58]<kriskowal> even made it pretty with pass/fail styled lines with silk icons. really fun [0:58]<kriskowal> yeah, i've seen stuff like that. i had my module loader keep an array of all messages that have been seen, and provided a hook so it could be flushed out to an alternate log if one was attached. [0:59]<kriskowal> the boomarklet approach is interesting [0:59]<kriskowal> wouldn't have been conceptually viable with chiron, since chiron didn't really leave anything in the global scope to reference into it [3:03]<Dantman> Upgraded the wiki a minor version. [21:36]<jbrantly> woohoo. My loader is passing unit tests :) [21:39]<dmachi> jbrantly: nice, what kind of loader is it? [21:43]<jbrantly> dmachi: browser-side [21:44]<dmachi> async? [21:46]<jbrantly> yes- it supports require.ensure plus normal requires() when inside a module. Dependencies are calculated and loaded prior to the factory functions running. [21:46]<jbrantly> lots more work to go but this is a nice milestone [21:47]<dmachi> is it standalone script? [21:47]<jbrantly> yes [21:48]<jbrantly> if you mean it doesn't rely on any third-party libs [21:48]<dmachi> public? (I'm writing a require() script right now becuase i havne't found an alternative) [21:49]<jbrantly> it will be, probably within the next few days. Not quite ready to release yet. More features, more tests, some cleanup work. [21:49]<dmachi> when you say the normal requires() when inside a module (I assume you mean relative modules) still work, does that imply that the relative ones are sync? [21:51]<jbrantly> dmachi: it never makes a synchronous XHR. Dependencies are determined via static analysis and loaded. So moduleA is loaded. It's determined that it does require('moduleB'). So moduleB is loaded. And so on until all dependencies are met. Then it runs moduleA. [21:52]<jbrantly> so no sync XHR, but potentially needs to load the entire codebase before executing a line of it. If you want to do lazy-loading, then require.ensure is there :) [21:52]<dmachi> cool. I have a dojo.require() that works just that same way, though with dojo.deferreds :) [21:53]<dmachi> ah, i did the analysis on the client side inspecting the src (admittedly brittle) as the files are downloaded. [21:53]<jbrantly> dmachi: right, same here [21:54]<jbrantly> dmachi: and yes, it is admittedly brittle :/ [21:54]<dmachi> i cheated embedded dojo.require()'s all got used, and to make that get skipped, i just do dojo['require'] [21:55]<dmachi> jbrantly: All that said, the larger system there is pretty good as its a serverside on-the-fly dependency resolution there too, so usually you don't get to that case. [21:55]<jbrantly> right now I'm doing XHR with eval. I plan on also supporting <script/> tags with pre-packaged modules, and bundling a packager/wrapper [21:56]<dmachi> Yeah [21:58]<dmachi> Though thats still not always the best solution for some cases. While it is _more_ async (script tags), its still not async [22:03]<jbrantly> yea. My goal here is just to get a general purpose loader that is small and provides options so it can be used in multiple ways. XHR vs <script>, hand-wrapped vs auto-wrapped, individual file loading vs one packaged file, sync (require) vs async (require.ensure). They all have their time and place, I think. [22:13]<dmachi> yep [22:14]<dmachi> I'm working on a commonjs module for Titanium, that basically provides the core loader and some of the core modules mapped to their lower level api [22:24]<jbrantly> you're creating a module or a loader? And you work for Appcelerator? [22:26]<dmachi> loader, no dont' work for appcelerator, just want to use some of my and others commonjs code :) [22:26]<dmachi> its a titaninum module implementing a commonjs loader to phrase it better [22:26]<jbrantly> ah gotcha [22:30]<jbrantly> well good luck :) and I'll try to let you know when I release [22:30]<dmachi> cool...was just asking before to see if i could steal it to save myself some work :P [22:34]<jbrantly> have you looked into RequireJS? [22:38]<dmachi> yeah, ive used it for some things (worked with jburke on dojo for a long time) [22:38]<jbrantly> ah ok [22:38]<dmachi> i just need a simple sync loader, so it shouldnt' be too bad. It just doesnt' seem to be defined reliably anywhere :)