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

2010-02-14:

[6:40] <kriskowal> hey sh1mmer, good to see you hanging out here.
[6:41] <sh1mmer> :)
[6:41] <sh1mmer> when my AT&T is working
[6:41] <kriskowal> i presume that word of our existence has found the y! ssjs folks
[6:41] <sh1mmer> no
[6:42] <sh1mmer> I've been here before
[6:42] <kriskowal> we talked in berlin
[6:42] <kriskowal> yeah
[6:42] <sh1mmer> i just forgot to put it on my automatic channel list
[6:42] <kriskowal> i only come in once in a while
[6:42] <sh1mmer> wait, I misread that.
[6:43] <kriskowal> i find that camping out here can consume an alarming amount of my attention
[6:43] <sh1mmer> I was talking to eric about making yui loader support module
[6:44] <kriskowal> it's an interesting idea
[6:44] <sh1mmer> well it's actually pretty close
[6:44] <sh1mmer> except for it's "use" instead of "require"
[6:44] <kriskowal> i think dojo and mochikit are moving in that direction, compiling commonjs modules to something suitable for their loaders
[6:45] <kriskowal> dojo was certainly an inspiration, but yui3 is very similar in spirit, yes
[6:46] <sh1mmer> use is effectively modules but via the network
[6:47] <sh1mmer> I'm trying to persuade them to make a synonym of require rather than having to load a module to make module work
[6:48] <kriskowal> or a thunk, i would hope, if it's not exactly the same.
[6:48] <kriskowal> i doubt that yui's use follows the relative module id resolution semantics
[6:48] <kriskowal> it would be a happy coincidence, anyway
[6:49] <kriskowal> i need to read yui3
[6:49] <sh1mmer> what's the difference between module 1.0 and 1.1?
[6:49] <kriskowal> prolly need to reread all the libs; they've all changed a lot over the last two years
[6:49] <kriskowal> not much
[6:50] <kriskowal> this amendment is the difference http://wiki.commonjs.org/wiki/Modules/Meta
[6:50] <sh1mmer> are you going to be a jsconf?
[6:50] <kriskowal> i have not signed up, and i think "the ship has sailed" if you know what i mean
[6:51] <kriskowal> i will be at google i/o, i think
[6:51] <kriskowal> and there's a strong chance i'll be in the bay area for the next ecma meeting, in march, i think
[6:52] <kriskowal> of course, this all depends on how much vacation time i have to burn on these things
[6:58] <sh1mmer> ok
[6:58] <sh1mmer> well lemme know
[6:59] <sh1mmer> maybe you want to come and speak at a bayjax
[9:39] <kriskowal> now accepting ideas for ways to construct a Date before 1900, and also after 9999
[9:40] <ondras> kriskowal: ha! finally I caught you on this channel :)
[9:40] * kriskowal runs away
[9:40] <ondras> I would like to have one question regarding the unit testing spec
[9:40] <kriskowal> ah, sure
[9:40] <kriskowal> i was thinking we might want to start a conversation to polish that up
[9:41] <ondras> 7.3. Other pairs that do not both pass typeof value == "object", equivalence is determined by ==.
[9:41] <ondras> this is a problematic formulation IMHO
[9:41] <ondras> what is the exact meaning of "do not both pass" ?
[9:41] <ondras> a != object || b != object
[9:41] <ondras> or
[9:41] <ondras> a != object && b != object
[9:41] <ondras> ?
[9:43] <kriskowal> if (typeof a !== "object" || typeof b !== "object") return a == b;
[9:44] <kriskowal> i see why that's confusing tho
[9:44] <ondras> (/me believes that result of "typeof" can be compared with ==)
[9:44] <ondras> but fine
[9:44] <ondras> I agree with you
[9:44] <kriskowal> both implies and, but there's an application of demorgan's theorem in the mix
[9:44] <ondras> and narwhal+fp impl is probably wrong now :)
[9:44] <ondras> (and v8cgi is correct yay! :)
[9:45] <kriskowal> i think that at this stage it's more productive to figure out whether the spec is right than whether the implementations match the spec, unfortunately
[9:45] <ondras> yeah, that's true
[9:45] <kriskowal> although, i'm glad you got it
[9:45] <ondras> on the other hand, it might be good to fix this formulation
[9:45] <ondras> it should be a very small change only
[9:45] <kriskowal> yes. it definitely is more clear in code
[9:46] <kriskowal> for sure, that needs to be more lucid
[9:46] <ondras> should I change that somehow?
[9:46] <ondras> or would you mind.. ?
[9:46] <ondras> (my english is probably not good enough..)
[9:47] <kriskowal> your english is good enough to tell whether it's clear to a non-native speaker, which it really ought to be
[9:47] <kriskowal> but the spec has convergence, so we should copy it and make a new proposal now
[9:47] <ondras> fine :)
[9:47] <kriskowal> or an amendment proposal with only the changed line
[9:47] <kriskowal> like Modules/Meta
[9:47] <ondras> so, which points are problematic now?
[9:48] <ondras> Known spec bugs in version 1.0:
[9:48] <kriskowal> well, let's start small
[9:48] <ondras> these?
[9:48] <kriskowal> yeah, those need to be addressed
[9:49] <ondras> we probably need to add another pair of assertions
[9:49] <ondras> deepStrictEqual and deepNotStrictEqual
[9:49] <ondras> (or notDeepStrictEqual?)
[9:50] <ondras> because there are 2 main assertions, each modifiable in 3 ways => 2^3 combinations
[9:50] <kriskowal> yeah, i know; that really rankles
[9:51] <kriskowal> i'm pretty unsatisfied by the strategy of making analogs of existing operators
[9:51] <ondras> and the rapid growth of assertion functions
[9:52] <ondras> *number of assertion functions
[9:52] <kriskowal> i'm glad that it won support, but i would also be much more happy with eq, ne, is, isnt where eq and is are *fixed* equality and identity, not the equality and identity we've had to deal with
[9:52] <kriskowal> mark miller posted some great code on identity checking
[9:52] <kriskowal> really shows how broken the primitives are
[10:47] <sh1mmer> kriskowal: still up?
[10:47] <kriskowal> aye
[10:47] <kriskowal> saturday is my 1 dr pepper per week
[10:47] <sh1mmer> heh
[10:47] <sh1mmer> I had one of the big red we brought back from tx
[10:48] <sh1mmer> so how does modules deal with promises?
[10:48] <kriskowal> they're orthogonal at the moment. promises are a higher architecture layer
[10:48] <sh1mmer> I'm looking at yui3 loader vs. how I read the modules spec and that's the main difference
[10:49] <kriskowal> we could do cool things with promises at the module layer, but since we did modules before promises (and promises are still very mushy atm), they aren't related yet
[10:49] <sh1mmer> yui3 is predicated on callbacks when the promise of a require is fulfilled
[10:49] <sh1mmer> right, that makes more sense in SSJS
[10:49] <kriskowal> ah, use returns a promise?
[10:49] <sh1mmer> but much less in client side
[10:50] <kriskowal> there certainly are complexities, but they're resolvable
[10:50] <sh1mmer> YUI.use("foo", function(Y) { //do shit when foo loads });
[10:50] <kriskowal> not beautifully though. it requires static analysis
[10:50] <kriskowal> yeah
[10:51] <kriskowal> so, in narwhal, we compile our commonjs modules to a "transport format"
[10:51] <kriskowal> the client loader receives the module factory functions via script injection
[10:51] <kriskowal> looks like register("foo", function (require, exports) {?}), vaguely
[10:52] <kriskowal> the register also takes the shallow dependency array of "foo", which we have to heuristically glean
[10:52] <kriskowal> the upshot is that we have to guarantee that the transitive dependencies of "foo" can be immediately required before we require "foo"
[10:52] <kriskowal> which is to say that the module functions have to be memoized
[10:52] <sh1mmer> right
[10:53] <sh1mmer> as far as I know YUI3 loader walks the transitive dependancies for you although I haven't looked into it in much detail
[10:53] <kriskowal> it certainly can if every "use" clause gets a block
[10:54] <sh1mmer> right
[10:54] <sh1mmer> I think it's actually slightly smarter
[10:54] <sh1mmer> because there are packages
[10:54] <sh1mmer> but that's more of a network optimization
[10:55] <kriskowal> i hope that the full signature is var promiseForX = use(id, function (moduleForId) {return valueForX}, function (error) {?});
[10:55] <kriskowal> that would correspond to full promise protocol, enabling graceful recovery and recursive deference
[10:56] <sh1mmer> actually interestingly there isn't an error callback
[10:56] <sh1mmer> http://developer.yahoo.com/yui/3/api/YUI.html#method_use
[10:56] <sh1mmer> that's a good point
[10:56] <kriskowal> ah
[10:57] <kriskowal> well, it's got room to grow
[10:57] <sh1mmer> even if it just threw an error on a timeout
[10:57] <kriskowal> i've gotta write up what i've learned about promises in the last few months.
[10:57] <sh1mmer> well I'm trying to think of the best way to reconcile our promise model with require
[10:57] <kriskowal> we're all learning this stuff as a group; it's like playing chess when you're a kid
[10:58] <sh1mmer> because right now it doesn't sit well with the style used in modules
[10:58] <kriskowal> you know, every kid is absolutely sure they know the rules to chess, and it always turns out that you don't agree after a few moves
[10:59] <sh1mmer> heh
[10:59] <sh1mmer> that's a good analogy
[10:59] <sh1mmer> (was captain of the chess team)
[10:59] <kriskowal> nice
[10:59] <sh1mmer> Oh I wasn't the best playert
[11:00] <kriskowal> nor was i. i mostly hung out and learned about patience and academic vigor the hard way.
[11:00] <sh1mmer> :)
[11:00] <sh1mmer> I was lucky, one of our math teachers played for England as a standby
[11:01] <sh1mmer> damn. I've gone all 'mercin. One of our maths teachers I should say.
[11:01] <kriskowal> ours was a disgruntled remedial math teacher and camp counselor that happened to pay for his college by winning chess games
[11:03] <kriskowal> sh1mmer, for ES+, we're hoping to introduce an import literal to replace the require function
[11:03] <sh1mmer> kriskowal: so do you think it's worth looking at a 1.2 which i more client friendly?
[11:03] <kriskowal> which would enforce the static analyzability of the shallow dependency graph
[11:03] <sh1mmer> ES+?
[11:03] <kriskowal> future ecmascript spec
[11:05] <kriskowal> the tension is that present require is very friendly to the developer and possible if messy to get working async, and async gets as curly as lisp is parenthy
[11:06] <sh1mmer> I would say that a callback should be optional
[11:06] <kriskowal> that's trixy
[11:07] <sh1mmer> maybe I can make the callback replace the promise with the object
[11:07] <kriskowal> i'm shooting for require.async(id):Promise and require.async(id, ok, error):Promise as a shortcut
[11:07] <kriskowal> node already does something like that
[11:07] <sh1mmer> yeah
[11:07] <kriskowal> and narwhal does that for the client impl
[11:07] <sh1mmer> and what does it do, throw?
[11:07] <sh1mmer> or just timeout until the promise is fullfilled?
[11:08] <kriskowal> the really crazy thing is that yui's use really *needs* to return a promise, which the module itself would then return to connote that its own exports are not yet ready
[11:08] <sh1mmer> well exports is tricky too
[11:08] <kriskowal> i presume that yui gets around that corner by mandating that all modules must call "use" at least once, and that the "use" hooks the module up with a promise implicitly
[11:09] <sh1mmer> because over the network it's much harder to fulfill partial promises
[11:09] <sh1mmer> it's all or nothing
[11:10] <kriskowal> yes, but you really need that error chain to set up solid recovery code, like try again in 10 seconds
[11:10] <sh1mmer> right
[11:10] <sh1mmer> that's easy enough
[11:11] <kriskowal> or logarithmic retry, with different architecture layers having as much user notification as possible to arrange with what's already been loaded
[11:11] <sh1mmer> I really want SPDY now
[11:11] <sh1mmer> because that would solve a lot of this stuff
[11:11] <kriskowal> yeah, my company would love it too; we're in the speed business
[11:11] <kriskowal> ah, not really. it would ease the pain though.
[11:12] <sh1mmer> spdy supports pipelining in a very convenient way
[11:12] <sh1mmer> so you could put functions in individual files
[11:12] <sh1mmer> and export them in priority order
[11:12] <sh1mmer> but retain caching
[11:13] <sh1mmer> so that you wouldn't redownload functions that hadn't changed
[11:13] <kriskowal> aye
[11:14] <sh1mmer> ok
[11:14] <sh1mmer> so I'm going to wrap use in a require syntax
[11:14] <sh1mmer> export won't be the same but it'll function the same to an end user
[12:12] <ondras> http://wtfjs.com/
[12:45] <Wes-> ondras: What's with your sudden fascination with people who don't understand JS? :)(
[12:46] <Wes-> ondras: Have you seen this, BTW? Input welcome: http://code.google.com/p/gpsee/wiki/JavaScript_FAQ
[13:02] <ondras> Wes-: yeah, you have shown me that recently
[13:03] <ondras> Wes-: also, I do not feel fascinated by those newbies, I am just reposting links I think other people might find interesting
[13:03] <Wes-> Ah
[13:03] <Wes-> The most recent link is interesting, goes to show that people do not understand var hoisting
[13:05] <ondras> Wes-: you might consider adding the example with return \n { stuff } semicolon
[13:05] <ondras> (as shown in "Good Parts")
[13:05] <Wes-> Yeah, I should also add something about var hoisting
[13:06] <Wes-> but return { object } semicolon insertion is a real bug that could bite me, as I don't like K&R-style bracketing
[13:06] <Wes-> (I like vertical alignment)
[13:06] <ondras> :)
[13:06] <Wes-> Oh, I have a note to do that under "pitfalls", just haven't written the text yet
[13:06] * ondras prefers K&R brackets
[13:07] <ondras> a line with only "{" looks weird to me
[13:07] <Wes-> it could be my heavy pascal/turing influence from early coding
[13:08] <ondras> it is a matter of taste imho
[13:08] <Wes-> Yes, it is. I personally find it hard to scan code for start/end-of block when they are not vertically aligned
[13:08] <Wes-> Of course, I also strongly prefer code which is not "deep"
[13:09] <Wes-> and I like 2-space indents
[13:09] <ondras> :)
[13:09] * ondras indents always by tabs
[13:09] <Wes-> well, I use the tab key, but I've told told emacs what to do with it. ;)
[13:09] <ondras> I find that more semantic than any number of spaces :)
[13:09] <ondras> hehe
[13:09] <ondras> afk, going downtown
[13:09] <ondras> detach
[13:20] * Dantman has preference for using tabs properly (ie tabs for leading indent, you don't make char precise indents with tabs), but Ruby has got me to use dual-spaces in some areas of code. but generally I LOATH 4-space indenting, it gives me nothing but trouble, especially with python.
[13:21] <Dantman> Proper tab usage ie: `\tvar foo = 1,\n\t bar = 2;` not `\tvar foo = 1,\n\t\tbar = 2;`
[13:22] <Dantman> mixed usage?

 

 

Logs by date :