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

2010-02-23:

[7:24] <ondras> hi!
[7:26] * Dantman is considering writing a Math.parse
[7:28] * ondras is angry because mozilla guys reject extensions which augment prototypes or use eval
[7:43] * Dantman thinks it should generally work like `Math.parse = function(expr) { return eval("with(Math) {"+expr+"}"); };` sans-eval would
[7:44] <Dantman> sans-anywierdbehavior
[7:45] <ondras> "with"! ruuun!
[7:45] <Dantman> ie: This should work: Math.parse("pow(sqrt(4), 2)");
[7:46] <Dantman> ondras, http://blog.danielfriesen.name/2009/05/28/with-obj-a-necessary-evil/
[7:47] <ondras> the thing is that "with" will not be here forever
[7:47] <ondras> if I am not mistaken, it might get removed from future ecma versions
[7:47] <Dantman> Mhmm...
[7:47] <aho> "should work like"
[7:47] <aho> doesn't really sound like he wants to use eval or with
[7:48] <Dantman> I doubt it'll get completely removed... generally I'd think the idea is to promote strict mode.
[7:48] <Dantman> Dropping it
[7:48] <Dantman> could make existing sites break
[7:50] <Dantman> ^_^ it's like using `JSON.parse = eval;` to parse JSON... It'll work for all the right cases, as well as some really wrong cases... but if you decide to depend on those wrong cases you're going to get shoved out of the way when actual implementations come into play.
[7:51] <Dantman> Ok, `JSON.parse = function(json) { return eval("("+json+")"); };` to be specific.
[7:52] <aho> well, "with" isn't just irritating and misleading, it's also slow
[7:53] <Dantman> And JSON doesn't allow your { foo: "bar" }, { "foo", 0010 }, or { "fn": function() {} } either ;)
[7:53] <Dantman> As for slow... more like, hard to optimize.
[8:21] <Dantman> Hmm, or maybe I should make that `Math.parse = function(expr, vars) { return eval("with(Math) {with(vars||{}) {"+expr+"}}"); };`
[8:27] <Dantman> Makes more sense to make use of JS' built in handling of variables, than to force an ugly user implementation.
[8:33] <aho> <Dantman> As for slow... more like, hard to optimize.
[8:33] <aho> same thing, really
[8:33] <aho> ;)
[8:34] <Dantman> Meh, that just means as per JS in the browser usage, it's not all that different in speed.
[8:34] <Dantman> Till you get to big stuff.
[8:36] <Dantman> Or rather, afaicr there aren't really many optimizations yet that with(){} would get in the way of, since it exists... you'd have to get into strict mode, and no-one really has that implemented yet.
[8:37] <Dantman> Shame, strict mode actually lessens the strange behavior of with(), you don't get unexpected globals by doing stupid things... You just get reference errors.
[8:40] <aho> well, if you got a with block it *can* mean something different each time you execute it
[8:40] <aho> makes crap native code, apparently
[8:40] <aho> ;>
[11:42] <ondras> hm
[11:43] <ondras> some tortoisegit user here? that crap is driving me insane
[12:11] <Dantman> tortoisegit is NG? Damn, there goes a good recommendation for a Windows git gui.
[12:11] <Dantman> tortoisesvn was popular among svn users
[12:12] <ondras> actually
[12:12] <ondras> it is not that bad
[12:12] <ondras> but I cannot find how to delete a branch
[12:12] <ondras> :)
[12:12] * Dantman uses a balance of terminal, `git gui`, and `gitk --all`
[12:14] <Dantman> The one thing I'd really want would be the ability to use git gui on a remote server without X
[12:14] <evilstreak> what does git gui give you that the terminal doesn't?
[12:15] <ondras> Dantman: ssh -X not enough?
[12:15] <Dantman> evilstreak, ^_^ It makes selecting chunks to go into the index for a commit much easier.
[12:16] * Dantman has never used ssh -X
[12:16] <ondras> Dantman: -X should solve all your problems :)
[12:16] <evilstreak> yeah, that's the one piece I really lean on gitx for
[12:16] <evilstreak> interactive staging in the terminal just isn't as easy
[12:17] <Dantman> Mhmmm, git add --patch is nice, but still does not compare to a gui that lets you go back and forth, navigate two separate lists, and individually move hunks and lines between the index and working tree
[12:17] <Dantman> Hmm, you know... now that I think about it, I might actually be able to use .gvfs
[12:21] <Dantman> Hmm, ssh -X looks interesting... Glad I know about it now... though it adds a bit of troublesome latency to gitk which already has it's own latency.
[12:25] <Dantman> Hmmm... this is a troublesome choice
[12:27] <Dantman> gitk over ssh -X slows down the ui... but gitk over .gvfs has ridiculous lag loading data... however the ui is nice and snappy, and once data is loaded the local cache makes the ui usable.
[12:29] * Dantman wonders if there is anything that works like Ubuntu One's syncing between a folder on a server and a folder on another computer.
[12:29] <Dantman> If I had that this would be no problem...
[12:30] <Dantman> Just have the data sync to the computer, then I could use the gui with absolutely no latency. (it is git after all, so where you commit is of little relevance)
[13:04] <Wes-_> Dantman: X rules. Way better than VNC/RDC when apps are written properly. If you want to improve further, see if your server supports lbx, the low-bandwidth extensions
[13:15] <Dantman> hmmm
[13:17] <Wes-_> Dantman: I have a fast fast DSL connection to my office with no internet in the way (just some routers). I can't even tell xemacs apart from running on my desktop.
[13:17] <Wes-_> Dantman: and I used to run olwm + xterms over dialup with lbx in the days of yore
[13:29] <Dantman> Tch, don't feel like going to the trouble of lbx since it doesn't seam setup in apt
[13:48] <ashb> Dantman|Sleep: you can ssh into the box - why not do an git clone locally and then push your changes?
[17:41] * ashb is having fun with regexs
[17:41] <ashb> SyntaxError: invalid quantifier *.*?\n)+[ \t]**\*{2}\/)
[17:41] <Wes-> god
[17:41] <Wes-> that looks like perl
[17:42] <ashb> its even worse as in the source i'm building it using the RegExp ctor
[17:42] <ashb> so its a bit unwieldy
[17:45] <Wes-> you should see the >> 10K regexps I use to parse system headers while building gpsee
[17:45] <Wes-> it's enough to make you want to cry
[17:45] <ondras> holy crap
[17:45] <ondras> in v8, [-1] is not a numeric index
[17:45] <ondras> :)
[17:46] <ondras> so an 'IndexedProperyHandler' (getter for numeric indexes) is not called
[17:46] <ashb> might be the same in SM actaully
[17:46] <ashb> (i wish that behaved like it did in perl)
[17:46] <ashb> @foo = (4,5,6); $foo[-1] == 6
[17:46] <ondras> :)
[17:47] <ondras> actually, this makes my B/F impl fail now
[17:47] <ashb> since they copied the negative things for slice and whatnot, they should have copied that too
[17:47] <ondras> because Kris's test expects [-1] to throw
[17:47] <ondras> omg
[17:47] <ondras> :)
[17:47] <ashb> what's your thought on his testing style?
[17:47] <ashb> specifically the wya of naming and the anount tested in a singel fn?
[17:47] <ondras> too much ".ok" assertions, no comments
[17:47] <ondras> *messages
[17:48] <ondras> well, the names are unorthodox
[17:48] <ashb> personally i'd prefer if they were clumped together more
[17:48] <ashb> i'm not a fan of religiously one assert per test
[17:48] <ondras> I have very little experience in this field
[17:48] <ashb> testing?
[17:49] <ashb> or this kind of testing?
[17:49] <ondras> both
[17:49] <ashb> k
[17:49] <ondras> I also tend to group multiple assertions together
[17:49] <ashb> my tests look like:
[17:49] <ondras> this is not quite possible with kris's style, as he completely ommits messages
[17:49] <ashb> http://github.com/evilstreak/markdown-js/blob/master/test/regressions.t.js#L491-505
[17:49] <ashb> sort of style
[17:50] <ondras> my look like http://code.google.com/p/v8cgi/source/browse/trunk/unit/tests/dom.js
[17:51] <ondras> (but I am far from being proud of them :) )
[17:51] <ashb> yeah - fairly similar
[17:51] <ashb> style wise
[17:52] <ondras> so, two more methods to finish in B/F, and then test+test+test+... :)
[18:41] <solidgoldpig> evening all
[18:41] <ashb> 'allo
[18:41] <solidgoldpig> how does one read a file these days?
[18:42] <solidgoldpig> used to be..
[18:42] <solidgoldpig> var FIle = require('file') etc
[18:42] <ashb> "var FILE" tells me you're using narwhal
[18:42] <solidgoldpig> but that's been supplanted by IO ?
[18:42] <solidgoldpig> ah no
[18:43] <solidgoldpig> actually Ash, I'm trying to use flusspferd ;)
[18:43] <ashb> oh win :)
[18:43] <Wes-> try var file = require("fs-base").openRaw(fileanme)
[18:43] <ashb> we've been a bit lax (we = commonjs_ of specifying file io
[18:43] <ashb> but require('fs-base')
[18:43] <ashb> http://flusspferd.org/docs/js/commonjs%20core/fs_base.html
[18:43] <solidgoldpig> hmm... I got an error trying require("fs-base")
[18:43] <Wes-> fs-base works almost everywhere to open files
[18:44] <solidgoldpig> but, I'll go again
[18:44] <Wes-> the problem is *reading* them afterwards, lol
[18:44] <ashb> solidgoldpig: what version are you on?
[18:44] <solidgoldpig> it'll work this time
[18:44] <solidgoldpig> bound to ;)
[18:44] <solidgoldpig> just upgraded to 0.9
[18:44] <ashb> also not that i'm a hero and called the metod openRaw not rawOpen like its meant to be
[18:44] <ashb> i think both are avaialble in 0.9
[18:45] <Wes-> ashb: openRaw is the right interface
[18:45] <ashb> right interface, wrong name is all
[18:45] <Wes-> no, right name too
[18:45] <Wes-> rawOpen is wrong
[18:45] <ashb> http://flusspferd.org/docs/js/commonjs%20core/fs_base.html#openraw-class_method
[18:46] <ashb> wrong name :)
[18:46] <ashb> solidgoldpig: require('fs-base') doesn't work?
[18:46] <solidgoldpig> require('fs-base') is indeed now working for me
[18:47] <Wes-> Well, you should keep openRaw then to be compatible with the CommonJS spec: http://wiki.commonjs.org/wiki/Filesystem/A/0#Files
[18:47] <ashb> i probably changed the docs then
[18:47] <Wes-> lol
[18:47] <Wes-> it has been openRaw forever AFAIK - that's all I ever implemented in gpsee
[18:48] <ashb> all of my code uses rawOpen
[18:48] <ashb> cos like i said - i'm a hero
[18:48] <ashb> solidgoldpig: all working then?
[18:48] <Wes-> heh
[18:49] <solidgoldpig> yep
[18:49] <solidgoldpig> except I'm now all sad that there are no easy read and write methods ;)
[18:49] <ashb> there are
[18:49] <solidgoldpig> where are they hiding?
[18:49] <ashb> http://flusspferd.org/0.9/docs/js/flusspferd%20core/io/file.html
[18:50] <solidgoldpig> ah right, openRaw gives me an IO File object
[18:50] <ashb> Yeah, the docs should perhaps be more clear on that point
[18:50] <Wes-> solidgoldpig: note that while openRaw() and other fs-base methods are CommonJS, that the read/write methods are not. (they have not been spec'd yet)
[18:50] <Wes-> Just something to keep in mind w.r.t. code structure for future-proofing
[18:50] <ashb> solidgoldpig: fancy knocking up a short doc patch?
[18:50] <Wes-> assuming you care about CommonJS portability, even
[18:51] <Wes-> Man, I can't get over how good this mass-produced, frozen Chicken Madras is
[18:51] <solidgoldpig> I fear for the hippo if I'm pathcing it ;)
[18:52] <ashb> solidgoldpig: it's all good
[18:52] <Wes-> just don't walk behind the hippo. ;)
[18:54] <ashb> solidgoldpig: so can we expect a patch then?
[18:55] <ondras> hm
[18:55] <ondras> http://gist.github.com/310702
[18:55] <ondras> L103-112
[18:55] <ondras> am I the only one confused here?
[18:56] <ashb> 112 looks like it sboule be buffer[1], 1)
[18:56] <ondras> yeah
[18:56] <ondras> so, my B/F seems to be ready
[18:56] <Wes-> B/F sounds like an acronym used in certain kinds of bars
[18:57] * ondras is not familiar with that
[18:57] <ondras> good for me I guess
[18:58] <Wes-> LOL yeah
[19:00] <ondras> http://acronyms.thefreedictionary.com/B%2FF
[19:00] <ondras> which one? :)
[19:01] <Wes-> Kinda like the first one, only "bum"
[19:01] <Wes-> It's also an acronym for what you can do with them
[19:04] <ondras> :}

 

 

Logs by date :