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

2009-12-06:

[0:09] <Wes-_> you know, it occurs to me that an event-driven javascript framework would make an awesome basis for a midi message processing system
[0:09] <Wes-_> anybody here familiar with opcode's Max?
[0:11] <MisterN> midi? as in music?
[0:17] <Wes-_> yeah!
[0:18] <MisterN> oO
[0:18] <MisterN> Wes-_: i only use midi when playing openttd :)
[0:19] <Wes-_> what's openttd?
[0:19] <MisterN> a game
[0:19] <Wes-_> oh
[0:19] <MisterN> http://www.openttd.org/en/
[0:19] <Wes-_> I haven't done raw midi in a very long time (since I was in school), but I had a good knack for it
[0:20] <Wes-_> I turned a midi-enabled mixing console into an input device that let me manipulate the oscillators and envelope shape for an FM tone generator
[0:20] <Wes-_> And then wrote a composition which required varying the timbre of the instrument while playing
[0:20] <Wes-_> it was really fun
[0:21] <MisterN> Wes-_: many programmers have skills in music.
[0:21] <MisterN> i don't
[0:21] <Wes-_> it's something that frequently goes together, or music+math is also common
[0:22] <Wes-_> too bad you don't, it's fun to have something else to sometimes :)
[0:22] <MisterN> but not always.
[0:22] <Wes-_> once upon a time I was working in a computer store, studying computers, and playing on them
[0:22] <MisterN> oh it's just not my thing and i don't want to like something because others tell me that i should
[0:22] <Wes-_> talk about a depressing life
[0:23] <Wes-_> if you don't like music, how about motorcycles?
[0:23] * Wes-_ likes those too
[0:23] <MisterN> no way. too scary
[0:23] <Wes-_> lol
[0:23] <Wes-_> you don't have to ride like an idiot to have fun
[0:24] <MisterN> i suppose it doesn't help that my vision has a certain kind of impairment.
[0:24] <Wes-_> I can't read road signs past 50kph
[0:24] <Wes-_> sssh don't tell the ministry of transportation
[0:25] <MisterN> and i don't like physically dangerous stuff
[0:25] <MisterN> even if it's just perceived danger
[0:25] <Wes-_> better stop showering then
[0:25] <Wes-_> my mom almost died in the shower a few years back
[0:25] <Wes-_> slipped and fell, very deep cut
[0:26] <MisterN> you know how perception isn't really objective.
[0:26] <Wes-_> that's true
[0:26] <Wes-_> I actually feel safer riding than driving
[0:26] <Wes-_> when you drive, your vision is obstructed
[0:27] <Wes-_> you can't react as fast
[0:27] <Wes-_> and you need a bigger hole to squeeze through when the shit hits the fan
[0:27] <Wes-_> also, I have a bad habit of nearly falling asleeping driving home from work
[0:27] <MisterN> on the other hand, the metal does give you a certain protection.
[0:27] <Wes-_> never a problem on two wheels
[0:27] <Wes-_> mistern: you know how perception isn't really objective. :)
[0:27] <MisterN> :)
[0:28] <Wes-_> although the falling-asleep thing really is a pretty big dangr
[0:28] <MisterN> Wes-_: when thinking of motorcycles i must always think of this guy who raced and then his leg got cut off by a road sign
[0:28] <Wes-_> heh
[0:29] <MisterN> i don't think that's a very funny thing to imagine! :P
[0:29] <Wes-_> there is danger everywhere
[0:29] <Wes-_> you have to balance joy:safety
[0:29] <Wes-_> a good understanding of statistics *does* help
[0:29] <Wes-_> the good news is, motorcycles eliminate the risk of seatbelt injuries
[0:30] <MisterN> and of getting choked by your airbags :)
[0:34] <ashb> Wes-_: and provide plenty of kidney and liver donors
[0:48] <ashb> Wes-_: Seen varnish btw?
[1:10] <Wes-_> haven't seen varnish, assuming you meant some money
[1:10] <Wes-_> I've got a can of varnish in my shop
[5:03] <Dantman> ashb, The web cache? ^_^ Wikia is using that for MediaWiki instead of Squid. after crucially got it working he said it was 20x faster than Squid.
[5:04] <Dantman> They switched cause Squid was working better under high load, but started to slow things down when load was lower,
[9:06] <rndmcnlly> has anyone built v8 on their mac?
[9:08] <progrium> when did serverjs become commonjs?
[9:15] <Dantman> Ages ago
[9:37] <ashb> Dantman: wikia uses varnish religiously
[9:42] <ashb> like you said.
[9:42] <ashb> Wes-_: http://varnish.projects.linpro.no/
[9:43] <ashb> Wes-_: the most interesting part of it is ESI: http://varnish.projects.linpro.no/wiki/ESIfeatures
[15:14] <Nadir_Seen_Fire> Mmm... would love something like http://nodebox.net/code/index.php/Graph for JS
[16:49] <Nadir_Seen_Fire> Tch, porting python to JS when you don't have ES5 isn't that fun
[16:49] <Nadir_Seen_Fire> And it's just making me hate python more
[16:49] <ashb> Nadir_Seen_Fire: ES5 is an offical spec now
[16:50] <ashb> start writing the bits that are missing for rhino
[16:50] <Nadir_Seen_Fire> I know, but I'm doing this client side.
[16:50] <ashb> ah
[16:50] <Nadir_Seen_Fire> T_T Getters/Setters
[16:50] <ashb> __defineObject__ if you dont care about IE :D
[16:50] <ashb> __defineGetter__ i mean
[17:01] <Wes-_> Nadir_Seen_Fire: You should try that python-to-javascript compiler! :)
[17:02] <Wes-_> I like the getter-in-object-literal syntax
[17:02] <Wes-_> (Is that ES5?)
[17:03] <ashb> no
[17:03] <ashb> ES-next
[17:03] <Nadir_Seen_Fire> pyjamas? heh, the statements on their homepage make me think they're really bad JS programmers
[17:04] <Nadir_Seen_Fire> getter in literal and more are part of harmony
[17:04] <Nadir_Seen_Fire> Mmm... const and proto
[17:04] <Nadir_Seen_Fire> http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_extensions
[17:05] <ashb> MisterN: thats not harmony then
[17:05] <ashb> http://wiki.ecmascript.org/doku.php?id=harmony:proposals
[17:05] <Nadir_Seen_Fire> Meh, strawman
[17:05] <Nadir_Seen_Fire> And...
[17:18] <ashb> deepEqual 4 "4"
[17:18] <ashb> assert.deepEqual(4,"4") even
[17:19] <ashb> what would you guys expect that to be?
[17:19] <inimino> depends on the equality semantics described in the documentation :)
[17:19] <ashb> ignoring that - your gut what would you expect it to be
[17:19] <ashb> also for (true,1)
[17:20] <inimino> I prefer false
[17:20] <inimino> http://boshi.inimino.org/3box/3box/util.js
[17:20] <inimino> scroll to the bottom, there's mine
[17:20] <ashb> false for both?
[17:21] <inimino> well, it would be insane for them to be different
[17:21] <ashb> true
[17:22] <inimino> either commit to === or ==
[17:22] <ashb> so its == it seems
[17:23] <inimino> I prefer ==
[17:23] <inimino> I mean ===
[17:23] <ashb> === but only at the item level?
[17:23] <inimino> I can't see any reason why a testing procedure should be unnecessarily loose
[17:23] <ashb> assert.strictEqual(x,y) is x===y
[17:23] <ashb> this is for the purposefully looser version
[17:24] <inimino> there is no other level
[17:25] <inimino> hm
[17:25] <inimino> I can't even see a reason to have it
[17:25] <Wes-_> I can't see how deepEqual(a,b) can reasonably be true when typeof(a) != typeof(b)
[17:25] <ashb> well 1 == true is true
[17:25] <ashb> as is 4 == "4"
[17:25] <Wes-_> well, yes, == coerces
[17:25] <Wes-_> I call it the "equivalent" operator
[17:26] <inimino> thats why == is wrong for deepEqual IMO
[17:26] <ashb> if oyu just want a simple x === y test, thats what the strictEqual fn is for
[17:26] <inimino> but is it deep?
[17:26] <ashb> no. iuts just x===y
[17:26] <inimino> then that's useless
[17:26] <Wes-_> and it's also deep
[17:26] <Wes-_> because it's an identity operator
[17:26] <ashb> but not in the way inimino means
[17:27] <Wes-_> inimino: are you looking for something that does deep-object comparison for equivalence?
[17:27] <inimino> you need a test for which f({a:0},{a:0}) == true and f({a:0},{a:"0"}) == false
[17:28] <inimino> and it should be the default, or ideally the only, deep comparison provided
[17:28] <ashb> oh also.
[17:28] <ashb> f(new Number(x), x)
[17:28] <ashb> is false
[17:28] <ashb> becasue of 7.3. Other pairs that do not both pass typeof value == "object", equivalence is determined by ==.
[17:28] <Wes-_> to do that properly, you need to traverse the object's properties recursively
[17:28] <ashb> so its broken anyway
[17:28] <Wes-_> checking primitives with ===
[17:29] <ashb> Wes-_: thats deepEqual does
[17:29] <inimino> f(new Number(x), x) should be false too
[17:29] <Wes-_> so then deepEqual matches what he's described
[17:29] <Wes-_> Yes it should
[17:30] <ashb> inimino: yes, but if f(4, "4") is true, then f(4, new Number(4)) should be true
[17:30] <Wes-_> I think the traversal should check both sides' typeof
[17:30] <Wes-_> (4, "4") should not be true
[17:30] <ashb> if either side is not typeof object then use ==
[17:30] <ashb> otherwise its inconsistent
[17:31] <ashb> which is far worse than just not doing what we expect it should
[17:31] <inimino> ashb: yes, I'm just saying they should both be false
[17:31] <ashb> inimino: fwiw i'm with you on that, cos it means i can just use Philipe Rathe's equiv.js :)
[17:46] <ashb> also its probably not right for regexp objects *STILL*
[17:48] <ashb> http://github.com/kriskowal/narwhal/blob/d89faead69fc9a4f75d4f7c3b772ead09d764c82/tests/commonjs/test.js
[17:48] <ashb> thoughts on that style of lots of tests
[17:48] <ashb> (and naming each one individually
[17:49] <ashb> makeBlock(assert.deepEqual, ["a"], {0:"a"})
[17:49] <ashb> WHAT?!
[17:50] <ashb> that should very much be false
[17:50] <inimino> opinions vary
[17:50] <ashb> the top level objects have different prototypes
[17:50] <ashb> '... equivalent values for every corresponding key, and an identical "prototype" property.'
[17:51] <inimino> mine makes that true
[17:51] <inimino> depends on whether you like duck typing or not
[17:51] <inimino> heh
[17:51] <ashb> to my reading its against the spec at least
[17:51] <inimino> definitely, then
[17:52] <Wes-_> those still have different prototypes
[17:52] <Wes-_> deepEquals should probably also make use of Object.equals
[17:52] <ashb> http://wiki.commonjs.org/wiki/Unit_Testing/1.0
[17:52] <ashb> someone want to read point 7. and see how you read it
[17:53] <ashb> wouldn't be the first time i've mis-read something
[17:53] <Wes-_> 7.3 is wrong INHO
[17:54] <ashb> ignoring that for now
[17:54] <ashb> (yes i think it is too)
[17:54] <Wes-_> it should not discuss typeof object,it should discuss typeof is not primitive
[17:54] <ashb> oh like that
[17:54] <Wes-_> the test up there fails same prototype
[17:55] <ashb> yeah
[17:56] <Wes-_> also, I think only checking ownProperties is wrong
[17:56] <inimino> no it doesn't
[17:56] <Wes-_> It assumes that properties on the prototype are only affected by enumerable ownProperties
[17:56] <ashb> inimino: ?
[17:56] <Wes-_> inimino: [].prototype != {}.prototype
[17:57] <inimino> [].prototype=={}.prototype
[17:57] <inimino> no...
[17:57] <Wes-_> Object and Array share a prototype? since when?
[17:57] <inimino> [].prototype === {}.prototype === undefined
[17:57] <ashb> thats a speclet bug then
[17:58] <ashb> [] behaving differently to new Array() behaving differently again seems wrong
[17:58] <ashb> you dont mean [].prototype
[17:58] <ashb> you mean __proto__
[17:58] <ashb> > [].__proto__ == {}.__proto__
[17:58] <ashb> false
[17:59] <inimino> you mean the spec writer meant __proto__
[17:59] <ashb> they didn't mean prototype property, yeah
[17:59] <ashb> they mean the objects [[Prototype]] or what ever the ES5 defn is
[18:00] <inimino> but since it explicitly mentions Arrays I don't know if that's what was meant or not
[18:00] <inimino> besides, __proto__ is nonstandard so if that is what they meant it's unimplementable
[18:00] <ashb> __proto__ is, but the intent behind it is implementable
[18:00] <Wes-_> js> Object.prototype.identify = "object prototype";
[18:00] <Wes-_> js> Array.prototype.identify = "array prototype";
[18:00] <Wes-_> js> [].__proto__.identify;
[18:00] <Wes-_> array prototype
[18:00] <Wes-_> js> ({}).__proto__.identify;
[18:00] <Wes-_> object prototype
[18:01] * ashb fires up the ECMA262-5
[18:01] <Wes-_> or, for that matter,
[18:01] <Wes-_> js> ({}).identify
[18:01] <Wes-_> object prototype
[18:02] <Wes-_> IIRC the spec says something along the lines of "[] is made as though the Array construct was called"
[18:02] <inimino> sure, [] and new Array() are equivalent as long as Array is the original Array object
[18:02] <ashb> Object.getPrototypeOf ( O )
[18:02] <Wes-_> and ES5 IIRC clarifies saying someting like "We meant Array as it was when the program started, regardless of whether it's been assigned since"
[18:02] <ashb> page #112
[18:03] <inimino> right
[18:03] <ashb> Object.getPrototypeOf([]) === Array.prototype
[18:03] <ashb> true
[18:03] <Wes-_> I think it's also painfully obvious that Object and Array don't share a prototype
[18:03] <Wes-_> most objects don't have push, pop, length, etc
[18:05] <inimino> sure
[18:37] <ashb> > assert.NdeepEqual(new RegExp("a", "g"),new RegExp("a"))
[18:37] <ashb> GAH I FUCKING SAID THIS 3 TIMES
[18:39] <ashb> (NdeepEqual being the dep-free version from node/narwha;)
[18:50] <ashb> kriskowal: dE(/a/, /a/g/) !== e(/a/,/a/g) as well btw
[18:51] <kriskowal> that brings up an interesting philosophical issue.
[18:51] <kriskowal> also, now that we have a unit testing api, we can start testing it with our unit testing api.
[18:52] <ashb> yay meta tests
[18:52] <kriskowal> writing up idealized unit tests and discussing each of them would probably be the best way to proceed
[18:53] <ashb> so i think if equal(x,y) is true then deepEqual(x,y) should also be true
[18:53] <kriskowal> philosophical question: should deepEqual and equal be equivalent for all non-compound objects?
[18:53] <kriskowal> equal is defined based on ==
[18:53] <kriskowal> which mark miller pointed out, is deeply flawed
[18:53] <ashb> dE doesn't imply e obv, but the reverse should be true. its certainly what i expected
[18:53] <kriskowal> furthermore, strictEqual isn't perfect either
[18:54] <ashb> inimino: was saying he basically wanted === at the item level but deeply
[18:54] <ashb> (if that makes sense)
[18:54] <kriskowal> i could buy the axiom, strictEqual is a subset of deepEqual
[18:55] <ashb> the other option of course is we have deepEqual and strictDeepEqual
[18:55] <ashb> but that is quite likely overkill
[18:57] <kriskowal> i'm contemplating the possibility, however remote, of basing both equal and deepEqual on the same, solid notions of equivalence.
[18:57] <kriskowal> and ditching strictEquals. it's a different approach.
[18:57] <ashb> good idea. will confuse Wes-_ tho, 'equivalance' to him is ===
[18:57] <kriskowal> the best way to make the case is with unit tests
[18:58] * ashb points at http://philrathe.com/articles/equiv again
[18:58] <inimino> if two things are distinguishable, they are not equivalent to all uses
[18:58] <inimino> equivalence is an extremely slippery idea
[18:58] <kriskowal> truly
[18:59] <kriskowal> markm's beef is that === isn't reflexive, because of NaN
[18:59] <kriskowal> also 0 and -0.
[18:59] <ashb> What about the x different types of NaN ;)
[19:00] <inimino> it shouldn't be, that's just the nature of NaN
[19:00] <inimino> you don't like it, take it up with IEEE ;)
[19:00] <kriskowal> i, actually, am on the fence. i tend to agree with the reasoning for the behavior of NaN
[19:00] <kriskowal> but markm is a darn smart fellow
[19:01] <inimino> I can see people wanting to do tests like assertEq(divide(1,0), NaN)
[19:01] <inimino> either way it needs to be documented
[19:01] <kriskowal> he was at parc labs
[19:01] <inimino> wow, didn't know that
[19:01] <ashb> inimino: yeah, test assertions are not the same as general purpose equals
[19:01] <kriskowal> and finder's column view was named after him
[19:02] <inimino> but I tend to like consistency
[19:02] <ashb> consistency is a must for me.
[19:04] <ashb> kriskowal: i can see the PoV that equal and deepEqual shouldn't always be half-relfexive
[19:05] <ashb> but i think the __proto__ thing is a flat out bug
[19:05] <ashb> deepEqual(new A(1), new B(1)) for the general case should certainly not be true, and special casing for plain objects/arrays seems not worth it
[19:05] <kriskowal> the intent was to preserve reflexive equivalence of constructors
[19:06] <kriskowal> so, whatever works.
[19:06] <ashb> 'reflexive equivalence of ctors'?
[19:06] <kriskowal> the clause might be unnecessary; i haven't thought it out
[19:06] <kriskowal> yeah. a is a constructor. a equals a
[19:06] <kriskowal> it's probably covered by the === catch
[19:06] <ashb> well a === a, so thats short circuited
[19:06] <ashb> yeah
[19:07] <ashb> and in general. ctors are functions, and the only time functiosn should be equal in any sense is ===, otherwise closure issues might ensue
[19:07] <ashb> & bbiab
[19:09] <inimino> ah, so the .prototype thing really was talking about the .prototype property, not __proto__
[21:31] <Dantman> Tch, porting this is taking awhile

 

 

Logs by date :