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

2011-01-10:

[18:46] <gozala> kriskowal: ping
[18:46] <kriskowal> pong
[18:46] <kriskowal> gozala^
[18:47] <gozala> I was wondering if you have decided what to do with Q.get(undefined, XX)
[18:49] <gozala> kriskowal ^
[18:50] <kriskowal> oh, my current development head is trapping exceptions and returning rejections. furthermore, there are traps in ref that provide more informative error/rejection messages
[18:51] <kriskowal> still rotating the code around to ascertain that errors don't silently disappear.
[18:51] <kriskowal> gozala^
[18:51] <Wes-> kriskowal: do you have the mental space to wade into the "eager factory evaluation is NOT a good idea" battle this week?
[18:52] <Wes-> I am having a hard time with the require explanations; that stuff is not my forte by any stretch
[18:52] <gozala> kriskowal: I also noticed that test don't pass with currently published version
[18:53] <kriskowal> gozala: i'll check
[18:53] <kriskowal> Wes-: not really, at the moment.
[18:53] <kriskowal> i've made the case so many times in the past though.
[18:54] <Wes-> kriskowal: The new argument -- get this -- is "since we're going to need something like require.async(), changing the semantics of module initialization will get lost in the noise"
[18:54] <kriskowal> but i'd have to wade through the new context, and honestly, i'm not interested in participating in the pro-boilerplate community
[18:54] <Wes-> some days I just feel like crying
[18:54] <Wes-> Yeah, I understand that that's not a favourite move for you
[18:55] <Wes-> FWIW - I'm completely against anything that changes semantics of contained modules away from a legal /1.1.1 interpretation
[18:55] <kriskowal> i'm far more interested in working in implementations that make the new shit irrelevant. modules/1.1.1 has a foothold and the right place to be working now is making it more pervasive
[18:56] <kriskowal> but, i also have no interest in waging a political battle against people trying to solve problems with their good but different set of requirements.
[18:56] <Wes-> *nod* - I recently implemented /1.1.1 without boilerplate in a browser environment built out of what I described as /2.0
[18:56] <kriskowal> i see.
[18:56] <Wes-> I'm still trying to find a better browser solution, though -- I don't like (but can live with) the boiler plate on the server end
[18:56] <kriskowal> the trouble with 2.0 is it is an aggregation of smaller efforts.
[18:57] <kriskowal> and it's also premature to give it a version number, like es4
[18:57] <Wes-> for perspective -- I am literally running the same libs server- and client-side these days as part of my main dev push
[18:57] <kriskowal> yeah, that's the way it ought to be.
[18:57] <Wes-> Yeah, you may have a point there
[18:57] <kriskowal> i think it needs to be broken up into a list of points to vote on with a summary of the subjective and objective issues on each point.
[18:58] <kriskowal> bite size
[18:58] <Wes-> Agreed - that has been plan all along (assuming it would come to a vote of any kind, which is not a given)
[18:58] <kriskowal> i also feel that there should be an overarching design, which is what you've done a good job setting out with
[18:58] <Wes-> Which is why I have been trying to pin james down on specific issues, rather than generalities
[18:59] <kriskowal> we should probably decouple the process of versioning the specifications from the process of determining what goes into new versions.
[18:59] <Wes-> thanks -- that's the biggest piece of the spec, IMO -- a common foundation that's clearly laid out
[18:59] <kriskowal> tc39 does this
[18:59] <Wes-> There are some major impl. differences in GPSEE from some of the other products, which I read as legal in /1.1.1 but frankly shouldn't be
[18:59] <Wes-> main module scope chain being the main offender
[18:59] <Wes-> kriskowal: that's an interesting idea
[18:59] <kriskowal> yeh, james and i feel much the same way: we are not interested in compromising on design. we are however interested in doing everything necessary to convince folks that it's the right way.
[19:00] <Wes-> I wonder if we could get some benefit from decoupling everything except the over-arching environment from the /2.0 moniker (which I have take to calling /2.0-draft7 so that I can have a /2.0-draft8 which is completely different)
[19:00] <kriskowal> that isn't to say that we haven't budged when we've found we wrong through discussion, or reduced scope to make progress
[19:01] <kriskowal> in any case, i've been focusing on promises, and it takes most of my mindshare after my application projects
[19:01] <Wes-> *nod* - FWIW, doing heavy browser-side work has given me a new appreciate of a wrapping, dep-specifying approach
[19:02] <Wes-> I was pleasant surprised to see how easy it was to build a CommonJS (on the server) module delivery system (to the browser) when that information is available
[19:02] <kriskowal> i think that the approach has merits given the state of the art.
[19:02] <kriskowal> but the effort is pretty free and loose on syntactic-convenience over strong-principles and invariants.
[19:03] <Wes-> kriskowal: *nod* - re. promises, have you had a chance to digest "module.eventually" in the draft I sent you? Goal was to allow a minimal shim on server-side envs like GPSEE so that they could essentially execute ~ setTimeout(0, callback)
[19:03] <kriskowal> for example, as you mentioned, separation of loading and execution
[19:03] <Wes-> idea being to keep semantics the same for callback invocation on client and server
[19:03] <kriskowal> also, i've seen too much code that has self-assigned module identifiers in the wild
[19:04] <kriskowal> to an extent, i'm guilty of doing the same with my optional <script> boilerplate, but i'd like to see it end.
[19:05] <kriskowal> i think i'm with mikeal on the issue of promises in modules. i think that having modules return or set their exports to promises is the way to go. there's no need for them to be conflated at the loader level.
[19:05] <Wes-> Likewise. There is fuzzy-space in there, where script needs to be able to assign module ids, so the jump to "well, why can't a script assign it's own id" happens easily
[19:06] <kriskowal> in any case, i think i need to do more research on packaging and modules to be a productive participant
[19:06] <Wes-> That's cool - you've certainly already done more than your fair share. :)
[19:06] <kriskowal> and probably the best advice i can give on making progress at the moment is procedural.
[19:07] <Wes-> I'm going to try and break up the latest proposal into pieces, and get them into better means somehow
[19:07] <kriskowal> that is, we need to train up on a process of frequently summarizing discussions and bringing discrete issues to the show of hands stage
[19:07] <Wes-> Yes
[19:07] <gozala> kriskowal: how would you recommend doing following:
[19:07] <kriskowal> and it can't just be one person doing it :P
[19:07] <Wes-> I wanted to get this together much sooner, thinking that it would be a trivial undertaking
[19:07] <gozala> Q.get(Q.get(undefined), 'foo')
[19:08] <gozala> Q.get(promise, 'foo')
[19:08] <kriskowal> everyone needs to start summarizing their impressions and what they believe other binding-vote participants believe
[19:08] <Wes-> paper-napkin shows I have about 200 hours invested in this now starting in Q3 2010
[19:08] <gozala> where promise is resolved to a falsy value
[19:08] <Wes-> but that includes sample implementations
[19:08] <kriskowal> yeah, you've overtaken me in total mailing list posts in the last few months.
[19:08] <Wes-> ha ha, yes, that's probably true
[19:09] <kriskowal> perhaps i'll have more time to corral discussions if i take a job with mozilla
[19:09] <kriskowal> i have a phone screen in 45 mins
[19:09] <kriskowal> i think.
[19:10] <kriskowal> gozala: can you clarify? get(undefined, 'foo') in my HEAD implementation returns a reject("cannot get property foo of undefined")
[19:10] <Wes-> Hey, that would be excellent; I think you would be a good addition to moz, particular around things like bespin, jetpack, maybe elsewhere
[19:10] <gozala> in current latest you get from npm
[19:10] <gozala> you get following
[19:11] <gozala> require('q').get(null, 'foo')
[19:11] <gozala> { emit: [Function], valueOf: [Function] }
[19:11] <gozala> > TypeError: Cannot read property 'foo' of null
[19:11] <gozala> at Object.get (/usr/local/lib/node/.npm/q/0.2.4/package/lib/q.js:275:26)
[19:11] <gozala> at Promise.emit (/usr/local/lib/node/.npm/q/0.2.4/package/lib/q.js:180:37)
[19:11] <gozala> at Array.0 (/usr/local/lib/node/.npm/q/0.2.4/package/lib/q.js:485:26)
[19:11] <gozala> at EventEmitter._tickCallback (node.js:60:24)
[19:11] <gozala> so error is logged but promise is not rejected
[19:12] <kriskowal> right, i've changed that in my dev copy to a rejection
[19:12] <kriskowal> i'm debating having a console.warn
[19:12] <gozala> you mean instead of console.error ?
[19:12] <kriskowal> i've been also working on q-comm, which may have implications on my implementation of def
[19:12] <gozala> or just removing all together ?
[19:13] <kriskowal> in the latest, the exception is caught and converted into a rejection. i'm considering putting a warning in case it doesn't get observed by a when clause
[19:13] <kriskowal> also thinking of adding annotations like andrew sutherland has in his fork for visualizing the dependency graph
[19:13] <gozala> I see
[19:14] <gozala> all that is great, but mind pushing at least
[19:14] <gozala> rejection firs
[19:14] <kriskowal> i may have pushed it as experimental
[19:14] <gozala> and then deciding on warnings and annotations ?
[19:15] <kriskowal> gozala, i guess i haven't. i'll push that up today, one way or another.
[19:16] <gozala> Thanks
[19:16] <gozala> I just pushed new version of teleport
[19:16] <gozala> which appeared to be broken
[19:16] <gozala> since I used my branch with this change inn :)
[19:17] <kriskowal> gozala: just pushed https://github.com/kriskowal/q/compare/master...experimental
[19:17] <kriskowal> having exceptions resolve to rejections has been good for q-comm
[19:17] <kriskowal> since it makes the error observable on both peers
[19:18] <kriskowal> fun to see node stack traces in a browser console :P
[19:18] <gozala> kriskowal: Thanks
[19:18] <gozala> can you also publish that in npm ?
[19:18] <kriskowal> not yet.
[19:19] <kriskowal> gozala^ it needs to bake for a while, exercising other code to see what breaks.
[19:19] <gozala> I think you can put ?dev flag
[19:20] <gozala> or something
[19:20] <gozala> I'm looking now how to do that
[19:20] <kriskowal> ok, thanks.
[20:07] <kriskowal> gozala: i've published v0.2.5 with duck typed promises and exceptions to rejections. enjoy.
[20:07] <gozala> Thanks!!

 

 

Logs by date :