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

2010-01-14:

[0:31] <ashb> tlrobinson: does narwhal have any way of mocking a module for testing purposes?
[0:31] <ashb> i.e. mocking the fs module?
[0:32] <ashb> tho having said that i now feel slightly iffy about mocking it
[0:32] <tlrobinson> i think so, you could create a sandbox and inject your mock module
[0:33] <ashb> basically i'm testing a function that calls fs.exists etc
[0:34] <ashb> if you think its possible in some way or other i will just bastract it behind a function
[0:34] <ashb> and worry about how to actually mock it in narwhal another time
[0:36] <tlrobinson> i think kriskowal would be the best person to ask. he knows more about dependency injection in narwhal
[0:38] <ashb> k - will ask him next time he's about if i remember
[0:39] <cpojer> isn't it just a matter of require('fsMock') ?
[0:39] <ashb> cpojer: no - cos the other module (the one i'm testing) will do require('fs-base')
[0:40] <cpojer> hm
[0:43] <cpojer> require(testing ? 'fs-base-mock' : 'fs-base') ;P
[0:43] <cpojer> or DEBUG for that matter
[0:43] <ashb> not really mocking then
[0:43] <SubtleGradient> lol
[0:44] <SubtleGradient> cpojer: although that is what we are all doing to you
[0:44] <SubtleGradient> ? mocking
[0:44] <cpojer> :(
[0:44] <ashb> SubtleGradient: harsh. but fair
[0:46] <SubtleGradient> i kid because I love
[0:46] <SubtleGradient> ? to abuse
[0:52] <SubtleGradient> ashb: what are you testing?
[0:52] <ashb> juice
[0:52] <ashb> using qmock
[0:53] <SubtleGradient> what's the purpose of mocking requires?
[0:54] <ashb> mocking fs methods
[0:54] <ashb> not strictly requires
[0:55] <SubtleGradient> ah, and since requires call the fs? gotcha
[1:44] <jmerlin> ondras: back yet?
[6:21] <tlrobinson> is the package spec missing "author"? http://wiki.commonjs.org/wiki/Packages/1.0
[9:37] <ondras> By convention, the first contributor is the original author of the package.
[9:37] <ondras> tlrobinson: ^
[14:27] <ondras> jmerlin: hi
[14:27] <ondras> jmerlin: I am located at GMT+1...
[14:28] <jmerlin> ah
[14:29] <jmerlin> GMT-6 here
[14:29] <ondras> jmerlin: so, back to your v8cgi question
[14:29] <jmerlin> i was reading the code to v8cgi and i didn't see how you were keeping modules from polluting the global object
[14:29] <ondras> well
[14:29] <ondras> first, the global object is accessible as a "global" variable
[14:29] <ondras> so everyone *can* access it
[14:29] <jmerlin> right
[14:29] <ondras> this is what you mean?
[14:30] <jmerlin> i mean when a module is called, the 'this' object essentially
[14:30] <ondras> ah
[14:30] <ondras> no
[14:30] <ondras> this === exports
[14:30] <ondras> :)
[14:31] <jmerlin> this.exports?
[14:31] <ondras> eh, no
[14:31] <ondras> have you already seen commonjs modules spec?
[14:31] <jmerlin> yeah, i'll probably implement it and i was reading how you did in v8cgi
[14:31] <ondras> fine
[14:31] <ondras> so you know
[14:31] <ondras> that in every module
[14:32] <ondras> there exists a free variable, "exports"
[14:32] <ondras> which is an Object
[14:32] <ondras> this variable's purpose is to let the module give some stuff to outside world
[14:32] <ondras> so a typical module does:
[14:32] <ondras> exports.someFunction = ...
[14:32] <ondras> exports.SomeClass = ...
[14:32] <ondras> etc
[14:32] <ondras> what is not exported is invisible from outside a module
[14:33] <ondras> it is completely necessary to understand this behavior
[14:34] <ashb> he's asking how you stop 'var foo' from creating a foo property on the global object i think
[14:35] <ondras> ashb: I am not sure - jmerlin explicitely asked about "this" in module
[14:36] <ondras> (which - imho - should be specified by commonjs as well!)
[14:36] <ashb> ondras: probably - but what to make it? ;)
[14:37] <ashb> sensibly choices are either module or exports i guess
[14:37] <ondras> yeah
[14:37] <ondras> one of these :)
[14:38] <evilstreak> exports
[14:38] <evilstreak> matches browser behaviour closest
[14:39] <evilstreak> default there is window, the global object
[14:39] <ashb> very true
[14:44] <jmerlin> yes it's about making objects in global visibility in a module and having them not be present in the global object
[14:45] <jmerlin> i didn't see any specific code to do that in v8cgi but in my shell, running another script that does 'var x = 1;' results in another module 'x == 1' and a for-in over 'this' which is the global object shows 'x' as an integer
[14:46] <ondras> "var x = 1" is fine in v8cgi
[14:47] <ondras> such variable is local to the module file
[14:47] <ondras> jmerlin: think of every module as being executed in an anonymous function
[15:00] <jmerlin> ah so that's why you call your loaded modules as a function?
[15:00] <ashb> we do the same thing on spidermonkey (now)
[15:01] <ashb> we used to create a new context for each module so even just "foo = x" with no var wouldn't polute, but that caused instanceof and JIT issues
[15:01] <jmerlin> right, that's what i was confused about
[15:01] <ashb> you now get a warning for foo = x if foo isn't a declared var in the scope somewhere
[15:01] <jmerlin> yeah
[15:01] <ashb> (thats a built in feature of spidermonkey)
[15:02] <jmerlin> but i do see that in v8cgi you cache the script handles ondras, is this preferred to caching the exports and just returning those on future require calls?
[15:06] <ashb> http://paulirish.com/work/gordon/demos/
[15:08] <jmerlin> wow
[15:08] <jmerlin> how does it compare to the binary player?
[15:09] <ashb> dunno.
[15:09] <ashb> how ever it compares its damn interesting
[15:11] <jmerlin> it's awesome really
[15:11] <jmerlin> no more flash players needed
[15:11] <jmerlin> :D
[15:11] <ondras> jmerlin: exports must be cached as per the spec, iirc
[15:11] <ondras> jmerlin: and the script caching is used when v8cgi runs as e.g. apache module, serving many requests repeatedly
[15:11] <jmerlin> ah
[15:12] <ondras> after a request is finished, its export cache is cleared
[15:12] <ondras> but the script cache is persistent
[15:12] <jmerlin> the performance of that flash player is only really acceptable on this machine running in chrome, the FF version i have it runs poorly in and IE8 it doesn't run at all
[15:12] * ondras tried the FF version on winxp this morning and it was fast
[15:12] <ondras> jmerlin: also note that IE does not support SVG
[15:13] <evilstreak> the biggest impact is iphone stuff, really
[15:13] <ashb> it probably falls back to VML
[15:13] <evilstreak> since in a desktop browser you may as well run the plugin
[15:13] <ashb> ondras: http://raphaeljs.com/pie.html
[15:13] <ashb> (i really like that pie chart. it *snaps* out of the page
[15:14] <jmerlin> evilstreak: yes but if i have an application with v8 embedded and it's my own app
[15:14] <jmerlin> and i'd like to play flash stuff
[15:14] <jmerlin> :p
[15:14] <jmerlin> that's just <3
[15:16] <SubtleGradient> someone want to implement SVG on the serverside?
[15:16] <ashb> define implement
[15:16] <ashb> SVG is just xml
[15:16] <evilstreak> I think they're pulling another developer onto a charting project here using raphael
[15:16] <SubtleGradient> good point
[15:16] <evilstreak> so I may be playing with that next week
[15:16] <SubtleGradient> ok, canvas then
[15:16] <SubtleGradient> so you'd be able to fallback canvas as png for IE or mobile or something
[15:17] <jmerlin> should rewrite gordon to use GL as well
[15:17] <oberhamsi> yeah smth like rhino-canvas but for commonjs would be awesome ;)
[15:17] <evilstreak> SubtleGradient: you can fallback canvas to VML
[15:17] <evilstreak> (for IE)
[15:17] <SubtleGradient> evilstreak: sure, but is there a way to convert VML to png?
[15:17] <evilstreak> nope
[15:17] <SubtleGradient> if you want to download or drag-to-desktop
[15:18] <SubtleGradient> also, does VML print?
[15:18] <evilstreak> it'd be useful, but it's not a game changer I think
[15:19] <ondras> ashb: iirc gordon does not use raphael
[15:19] <ashb> ondras: didn't look. it could do tho
[15:19] <oberhamsi> what i've seen gordon does it's own canvas stuff, no raphael
[15:20] <ondras> http://github.com/tobeytailor/gordon/tree/master/src/
[15:20] <ondras> look here
[15:20] <oberhamsi> they guy - is he around? - did tweending libs for canvas, later a vector lib.. i guess the flash player was the logical next step
[15:20] <ondras> no vml apparently
[15:20] <ondras> the problem with these compatibility layers is
[15:20] <oberhamsi> ^^ tweending
[15:20] <ondras> that there is frequently some obscure feature
[15:20] <oberhamsi> vml is dead slow, not comporable to canvas
[15:20] <ondras> which is necessary and not already bridged
[15:20] <ondras> :)
[15:21] <oberhamsi> can't write "tweening" it seems
[15:21] <SubtleGradient> VML is more like SVG
[15:21] <ondras> (as per-pixel access in iecanvas)
[15:21] <oberhamsi> agreed, VML is ok for static stuff
[15:21] <SubtleGradient> or mildly interactive stuff
[15:21] <SubtleGradient> since it's element based like svg
[15:21] <ondras> oberhamsi: those are not truly comparable...
[15:21] <ondras> one cannot compare vector and raster formats
[15:21] <ondras> ...
[15:21] <SubtleGradient> so you can have events and stuff on the VML/SVG elements
[15:22] <oberhamsi> ondras: comparable for practical purposes
[15:22] <oberhamsi> the api canvas offers is mostly vector oriented anyways
[15:23] <ondras> once the elements are draw, they are lost forever
[15:23] <ondras> *drawn
[15:23] <SubtleGradient> good thing canvas redraw speed is to insanely fast
[15:23] <ondras> it is surely more raster than vector based
[15:24] <ondras> yeah, canvas's fast
[15:24] <ondras> http://tmp.zarovi.cz/maze/
[15:24] <ondras> .)
[15:24] <SubtleGradient> It seems like it was designed to be able to have a nice layer of script sugar on top
[15:25] <evilstreak> raphael uses SVG to support interaction
[15:25] <oberhamsi> canvas is more raster based, but like the gordon guy you can ignore that :) flash is vector after all
[15:25] <SubtleGradient> i.e. intentionally kindof raw
[15:26] <SubtleGradient> everything is raster since we have raster screens. it's just at what level of abstraction the actual rasterization happens
[15:26] <SubtleGradient> e.g. so you could implement SVG rendering using Canvas
[15:27] <SubtleGradient> but thankfully good browsers has an SVG render built-in
[15:34] <jmerlin> and what does Canvas use to render?
[15:37] <ondras> jmerlin: canvas accepts per-pixel as well as geometry-like commands to draw them to a memory-less pixel grid
[15:37] <jmerlin> sounds inefficient
[15:38] <ondras> why?
[15:38] <ondras> it is really very fast
[15:38] <ondras> there is no memory overhead
[15:38] <ondras> once a stuff is drawn, it is thrown away
[15:38] <jmerlin> for animations at 30+fps?
[15:38] <ondras> actually, yes :)
[15:39] <ondras> canvas is - at the moment - the fastest non-accelerated non-flash drawing tool we have :)
[15:39] <MisterN> ondras: isn't SVG relatively fast too?
[15:39] <ashb> also you only need about half that for visually smooth FPS (so long as it is consistenyl at least 15fps)
[15:40] <jmerlin> i'd love to see GL standardized across browsers for JS
[15:40] <ondras> MisterN: svg is also not bad
[15:40] <ashb> jmerlin: WebGL
[15:40] <MisterN> because raphael uses svg
[15:40] <ondras> MisterN: but I do not like comparisons of these, because - as I said - they are here for different purposes
[15:40] <ashb> http://en.wikipedia.org/wiki/WebGL
[15:40] <ondras> it is like comparing midi to wav
[15:40] <ondras> .)
[15:41] <MisterN> ondras: dunno once you have a graphics frontend in JS that uses svg/vml/canvas/whatever on the backend, you might want to compare them
[15:42] <ondras> once you have both apples and oranges in your fridge, you might want to compare them :)
[15:42] <jmerlin> ondras: WebGL cannot come fast enough, once vectored libraries are running with an accelerated back-end, woot.
[15:42] <MisterN> ondras: yes.
[15:42] <jmerlin> re-write q3 with javascript lol
[15:43] <ondras> btw, raphael is more of a compatibility layer, providing consistent api across svg+vml
[15:43] <MisterN> ondras: it'd be even better in german because we don't say "apples and oranges" but "apples and pears", which is funny to me, because apple and pears are closely related fruits
[15:43] <ashb> stairs
[15:43] <ondras> MisterN: yeah, we have the same (apples and pears) in czech
[15:43] <evilstreak> up the pears!
[15:44] <jmerlin> pears <3
[15:44] * ashb wonders how many people me and evilstreak just confused
[15:44] <MisterN> apples and stears
[15:44] <MisterN> stairs!
[15:44] <MisterN> lol
[15:45] <ashb> cockney rhyming slang
[15:48] <jmerlin> meh.. cockney
[15:50] * oberhamsi finds canvas a lot more sexy then svg/vml
[15:51] <ondras> hehe
[15:51] <ondras> as long as you don't need event handlers...
[15:52] <oberhamsi> nope... sdl doesn't have event handlers either and works good for games :P
[15:52] <oberhamsi> i wrote a simpler gameapi ontop of canvas and was impressed by the speed
[15:52] <ondras> so what vector advantages remain now?
[15:52] <ondras> size
[15:52] <ondras> and scalability :)
[15:53] <ashb> oberhamsi: doesn't have event handlers, but it does have events/IOC
[15:53] <oberhamsi> and easier computer readiblity
[15:53] <ondras> yes
[15:53] <ondras> some level of semanticity
[15:53] <oberhamsi> ashb: yes... you get mouseX/Y and such. but i can calc those for canvas just fine
[15:55] <oberhamsi> and what's "ioc" .. probably nothing to do with olympics?
[15:55] <ashb> Inversion of Control
[15:56] <oberhamsi> ah
[15:57] <oberhamsi> hm, always seemed more natural to me that way. having the events right on the objects was the inversion for me :)
[16:16] <cpojer> does an environment exist that has real secure modules in terms of native types?
[16:17] <cpojer> like where you can do require('foreignNative').String !== String
[16:18] <ashb> ours used to do that - but it was more annoying that way
[16:18] <SubtleGradient> ashb: which one is "ours"?
[16:19] <ashb> flusspferd
[16:19] <cpojer> ah
[16:19] <ashb> aka hippo
[16:19] <MisterN> ashb: we used to do that?
[16:20] <cpojer> I suppose it would be very confusing for most users
[16:20] <ashb> instanceof was broken at one point between modules anyway
[16:20] <ashb> MisterN: so unintentionally
[16:20] <MisterN> ashb: lol.
[16:20] <ashb> cpojer: yeah, it was. certainly if you aren't expecting it
[16:20] <MisterN> ashb: wasn't that due to a bug in spidermonkey?
[16:21] <ashb> dont think so - it was cos of the tricks we played with globals
[16:21] <cpojer> ashb: is there any environment that prevents me from adding something to String.prototype or String for that matter?
[16:21] <ashb> cpojer: caja maybe
[16:21] <cpojer> or, do you think it is likely that this will happen at some point?
[16:22] <cpojer> yah caja, possibly
[16:22] <ashb> cpojer: dunno. why?
[16:22] <cpojer> mootools specific
[16:22] <MisterN> cpojer: not in spidermonkey. they fear that even the most reasonable change would break things :)
[16:22] <ashb> oh you are wondering if its bad to put things there?
[16:22] <cpojer> no
[16:22] <MisterN> cpojer: but you can use caja or something like that
[16:22] <cpojer> we do it, we know the implications
[16:22] <cpojer> and it is probably a core selling point of mootools, that we try to extend javascript
[16:22] <cpojer> and this will most probably change
[16:23] <ashb> so long as you dont touch Array.proto or Object.proto :)
[16:23] <cpojer> we totally touch Array.prototype
[16:23] <cpojer> but mainly to add functionality for IE6, like some, map, every etc.
[16:23] <ashb> not a fan of that.
[16:23] <cpojer> but if we go for commonjs (we are really pushing it) we want to play by the rules
[16:23] <ashb> i have an intense dislike of code that makes me use hasOwnProperty
[16:23] <cpojer> well I do not think it is an issue for array
[16:24] <MisterN> ashb: well i'd use hasOwnProperty just for safety anyways
[16:24] <deanlandolt> aren't the commonjs "rules" that you can extend Object.prototype and Array.prototype to shim in the es5 features?
[16:24] <cpojer> you shouldn't be doing for (i in array)
[16:24] <ashb> cpojer: in commonjs you should be able to use Object.defineProperty anyway
[16:24] <ashb> cpojer: not if i know its an array :)
[16:24] <cpojer> ashb: lets say, you can if you know what you are doing
[16:24] <MisterN> ashb: we have standardised that implementations patch in Object.defineProperty?
[16:24] <cpojer> but most users don't :)
[16:25] <cpojer> ashb: we need to remain compatible with browsers, but I suppose Object.defineProperty can be implemented just like that
[16:25] <ashb> MisterN: um i think spidermonkey has it now. but i guess it didn't 6mo ago
[16:25] <ashb> cpojer: if it exists, use it etc.
[16:25] <MisterN> ashb: i know we had it 6 months ago :)
[16:25] <cpojer> ashb: we should look into it :)
[16:25] <cpojer> or, I :D
[16:25] <ashb> cpojer: the main advtange is you can create non-enumerable props
[16:25] <ashb> also non-deletabe props
[16:25] <cpojer> yah
[16:26] <cpojer> I think I learned about that stuff half a year ago
[16:26] <cpojer> but since es5 does not exist really I forgot about it
[16:26] <cpojer> I know its a standard
[16:26] <ashb> so all non-browser commonjs platforms should implement it (and its possible to implement in that native bits of every engine)
[16:26] <MisterN> cpojer: flusspferd implements it when the javascript engine doesn't
[16:28] <oberhamsi> hm.. for (i in array) is encouraged by rhino, they advertised list comprehension
[16:28] <cpojer> well it is probably faster than forEach but I do not see any other advantage
[16:29] <ashb> for each (i in array) <-- best thing to come out of e4x
[16:29] <ashb> if only more engines implemented (At least) that
[16:30] <oberhamsi> cpojer: [x for (x in [1,2,3]) if (x%2==0)]
[16:30] <oberhamsi> :)
[16:30] <cpojer> hah
[16:31] <cpojer> it is so awesome how mutable javascript is
[16:31] <cpojer> but the sad thing is you cannot use these things until 2020 if you still support IE6 on the clientside
[16:31] <ashb> we should really say that a console object should be available as a global free variable too
[16:31] <MisterN> lolol IE6
[16:31] <cpojer> ashb: totally
[16:31] <evilstreak> +1
[16:32] <evilstreak> (especially since I raised it yesterday)
[16:32] <ashb> i guess we could do console = require('console') instead
[16:32] <cpojer> It should be a commonjs standard
[16:32] <evilstreak> it's the defacto browser standard
[16:32] <evilstreak> it makes sense to use the same, instead of print() methods and whatnot
[16:32] <evilstreak> way better compatability for code used on both client and server
[16:34] <jmerlin> i prefer IE3
[16:34] <cpojer> IE6 is an amazing browser, ten years ago
[16:36] <MisterN> cpojer: and it will be used the next ten years in backward firms, i fear.
[16:36] <cpojer> official support until 2014
[16:36] <cpojer> but seriously, in 2015 we will have hoverboards, who will still be sitting in front of a computer by then?
[16:37] <oberhamsi> ugh... 2014. i would pay to get it removed asap :)
[16:38] <MisterN> cpojer: we'll all have iPhones that can change their physical size whenever needed, clearly ;)
[16:38] <cpojer> boo :P android ftw.
[16:40] <MisterN> cpojer: heh. i actually have a Hero, no iPhone. :P
[16:40] <cpojer> :D
[16:41] <evilstreak> move into lines of work which don't involve backwards clients
[16:41] <evilstreak> then you don't need to worry about it
[16:41] <evilstreak> (sadly, that means not working on libraries like mootools)
[16:42] <cpojer> I'm in the lucky position where a) my code doesn't have to work in IE6 b) my code works automatically in IE8, without any adjustments needed
[16:43] <MisterN> evilstreak: pipe dream, eh? :P
[17:08] <evilstreak> MisterN: I mostly work on stuff that doesn't worry about it
[17:09] <MisterN> evilstreak: no public websites, then?
[17:09] <evilstreak> not all public websites have to support IE6
[17:10] <evilstreak> unless by public you mean government
[17:10] <evilstreak> in which case no, I do not work on those
[17:10] <evilstreak> they get done by government types (mostly not very well)
[17:10] <Wes--> ashb: Heads up - I changed fs-base.exports.link to fs-base.exports.symbolicLink in spec
[17:10] <ashb> Wes--: ah k
[17:10] <ashb> will change to have both for now
[17:10] <MisterN> evilstreak: dunno, many public websites will support IE6 because they want everybody to be able to view the page
[17:13] <ashb> Wes--: readLink stays as is?
[17:13] <Wes--> ashb: yes
[17:13] <Wes--> isLink too
[17:13] <ashb> k
[17:14] <ashb> done.
[17:15] <Wes--> also, new API, sameFilesystem
[17:15] <Wes--> slightly tricky-to-write, but important for persons wanting accurate move() control/info
[17:15] <ashb> compare stat entries, no?
[17:15] <ashb> devno or whatever the field is
[17:17] <evilstreak> MisterN: view !== have full functionality
[17:17] <evilstreak> it's a cost/benefit thing
[17:17] <Wes--> ashb: Yes, for the case when the paths both exist, otherwise backtrack until you find one that does. struct stat.st_dev FWIW IIRC
[17:17] <ashb> ah.
[17:18] <ashb> Wes--: shouldn't the targets have to exist?
[17:18] <evilstreak> the cost of providing IE6 users with as rich an experience as other browsers is often not worth it
[17:18] <evilstreak> (sadly though, it sometimes is)
[17:19] <Wes--> ashb: no, the whole point is to figure out if you can move() without copy
[17:20] <ashb> that means move will also do the effect of mkdir -p ?
[17:20] <Wes--> ashb: No, you would have to make the intermediary directories yourself -- but making those directories just to see if you can move() a file into them would be silly
[17:21] <ashb> i dunno - it seems wrong to backtrack up like that
[17:21] <ashb> if oyu have to work out what dirs dont exist, you have to backtrack yourself anyway
[17:21] <ashb> so why not check once you've backtracked up?
[17:22] <MisterN> evilstreak: well but giving them even a basic experience is annoying too, isn't it?
[17:22] <evilstreak> nope
[17:22] <evilstreak> remove all CSS, remove all JS, job's a good'un
[17:22] <ashb> Wes--: if you really think its worth it its not that hard to do with boost fs so I dont mind. it just seems a bit odd is all
[17:22] <MisterN> lol that's a very basic experience then
[17:23] <evilstreak> ok, so that's a bit OTT, but you can really cut out polish if you treat it as a second grade browser
[17:23] <MisterN> which it is.
[17:23] <Wes--> ashb: you have to *at least* support that the file does not exist, or almost all code using this function will be silly;
[17:24] <ashb> Wes--: true, i guess you'd have to manually remove the filename yourself.
[17:24] <Wes--> if (sameFilesystem(a,b) || sameFilesystem(a,b.split['/'].unshift().join)) move(a,b)
[17:24] <Wes--> yeah
[17:24] <ashb> bear in mind tho, that i'm not sure that java will be able to implement sameFilesystem
[17:24] <ashb> i very much doubt you can get that sort of info from java
[17:24] <Wes--> ashb: java can't do half the stuff in fs-base without JNI anyhow
[17:25] <ashb> heh
[17:25] <Wes--> hence the narhwal system("chmod") calls etc
[17:25] <ashb> ah
[17:43] <Wes--> ashb: suspect this impl is sufficient -- http://pastebin.mozilla.org/697101
[18:49] <Wes--> Dantman: Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.
[18:49] <Wes--> Dantman: I see that all the time, should I?
[19:19] <Dantman> Wes--, all the time?
[19:19] <Wes--> Dantman: well, often
[19:20] <Wes--> three times today already
[19:23] <Wes--> Dantman: also, that box is wicked slow ATM for some reason
[19:24] <Wes--> hdon: http://wiki.commonjs.org/wiki/Filesystem/A/0#Listing
[19:25] <Wes--> hdon: trying to understand if that (without prev) can be implemented with generators
[19:26] <hdon> Wes--, yes. generators are constructor functions for an iterator object, an "iterator object" being defined as an object with a next() method and throwing StopIteration to signify the end of the list
[19:27] <hdon> Wes--, the only caveats here may be that the current spec seems to expect prev() and close() :\
[19:27] <hdon> i would vote against prev() and close()
[19:27] <Dantman> Wes--, the speed issue was memcached being down
[19:27] <hdon> actually i guess close() is important
[19:28] <hdon> Wes--, did you mean to point me to #Listing?
[19:28] <hdon> should i read the whole thing now?
[19:28] <Wes--> hdon: just the listing sectino
[19:28] <Wes--> specifically the iterator method
[19:28] <Wes--> er, iterate()
[19:28] <Dantman> I'm not sure about the sessions though... Using default session settings. We're not using memcached sessions iirc so that shouldn't be the issue. And the session path isn't /tmp so I can't think of anything that would unexpectedly blank it.
[19:30] <Wes--> dantman: weird. Last time this happened, I clicked the save button 4 times before it saved
[19:30] <Wes--> so you wouldn't think timeout was the problem either
[19:30] <Wes--> hdon: trying to figure out if this is enough to implement the spec (excluding prev): http://code.google.com/p/gpsee/source/browse/modules/fs-base/fs-base_module.js#584
[19:30] <Wes--> hdon: And if not, how to implement??
[19:30] <hdon> Wes--, we can use a generator, but unfortunately it looks like the elegance of the generator won't buy us much here, if we're expected to support prev(), and close() (i'm in favor of close, prev() i find pretty useless)
[19:31] * hdon clicks
[19:31] <hdon> Wes--, well that's still missing close(). allow me to suggest a patch, one sec...
[19:31] <Wes--> hdon: yeah, planning to remove prev from the spec, not sure what close is supposed to do (or how to implement?)
[19:34] <hdon> Wes--, wait, that isn't finished is it?
[19:35] <Wes--> hdon: finished, yes, tested, no. :D
[19:35] <hdon> Wes--, close is supposed to destroy the iterator's resources (like closedir())
[19:35] <Wes--> (do you see a problem?)
[19:35] <Wes--> Oh, I should also be closedir'ing in that function
[19:36] <hdon> no i deleted a line accidentally while editing, lol
[19:36] <Wes--> is it possible to implement close() without going native?
[19:36] <hdon> why? we have the perfect means of doing close() with GFFI automatic GC finalizers
[19:36] <hdon> dirent.finalizeWith(closedir, dirent)
[19:37] <Wes--> you're right about the finalizer being the right solution to closedir
[19:37] <hdon> and then the close() method can be implemented with the GFFI method for explicitly invoking the finalizer
[19:37] <Wes--> but that doesn't implement close()
[19:37] * hdon continues his patch
[19:37] <Wes--> ....should close() be a property of the thing that's yielded?
[19:38] * Wes-- is thoroughly confused
[19:40] <hdon> http://pastebin.mozilla.org/697123
[19:40] <hdon> Wes--, ^^ that's my suggestion
[19:40] <hdon> granted it uses a rather obscure javascript feature
[19:41] * hdon wonders if supported by sm
[19:42] <Wes--> hdon: "runFinalizer" - should be destroy, no?
[19:42] <Wes--> And, what happens with a file named close?
[19:43] <hdon> Wes--, i named it runFinalizer cause i thought it was more explicit
[19:43] <hdon> Wes--, that presents no problem, but i'm gonna hop into #jsapi and ask if they support this feature. an experiment says no
[19:43] <Wes--> crap
[19:43] <Wes--> I have code using destroy()
[19:44] <hdon> Wes--, oh i used it wrong
[19:44] <hdon> Wes--, i guess we could make destroy an alias for runFinalizer
[19:44] <Wes--> when did you change that?
[19:45] <hdon> Wes--, updated http://pastebin.mozilla.org/697127
[19:45] <hdon> Wes--, it was never destroy(), only in conversation possibly
[19:46] <Wes--> hdon: gffi_module.js line 81
[19:46] <hdon> Wes--, oh, you're right. sorry
[19:46] * hdon smacks his head
[19:47] <Wes--> hdon: your iterate() impl looks reasonable
[19:47] <Wes--> hdon: would you mind patching, quick-testing and pushing?
[19:48] <hdon> Wes--, ok
[19:49] <Wes--> hdon: although, could you have "close" break the loop, and fall through to bottom where dent.destroy() runs? So we _closedir() either way.
[19:49] <hdon> ah good call
[19:50] * Wes-- is really happy to see fs-base taking shape
[19:50] <hdon> me too
[19:53] <jmerlin> ondras: still around?
[19:53] <ondras> jmerlin: a bit
[19:54] <ondras> will detach in few minutes
[19:54] <ondras> but feel free to ask
[19:55] <jmerlin> so in v8cgi, if you declare a variable without using 'var', it will go into the global scope regardless? wrapping it in an anonymous function shouldn't separate it completely
[19:55] <ondras> yes
[19:55] <ondras> as you said
[19:56] <ondras> (the same will happen if you assign to global.someproperty)
[19:56] <ondras> well, not exactly the same i presume
[19:56] <ondras> doing "a=3" will create a DontDelete property .)
[19:57] <ondras> aha, it won't
[19:57] <ondras> interesting
[19:57] <Wes--> jmerlin: more specifically, non-var variable declarations in CommonJS have undefined behaviour
[19:57] <ondras> hm
[19:57] <ondras> that DontDelete stuff should not be experimented with in firebug
[19:58] <ondras> .)
[19:59] <ondras> Wes--: and the same applies to "this" in module code. What is your opinion to standardizing this in some way?
[19:59] <ondras> *on standardizing
[20:00] <Wes--> ondras: I think standardizing is probably a bad choice, frankly
[20:01] <ondras> so you just propose not to use it?
[20:02] <Wes--> ondras: precisely - it is poorly specified in the language outside of instance methods, and is basically a side effect of how the program/module is implemented
[20:03] <ondras> well, discouraging usage is also something I would support
[20:03] <ondras> better than saying nothing :)
[20:04] <Wes--> ashb: added require("fs-base").openRaw().close() FWIW
[20:04] <Wes--> ondras: saying that something is undefined is active discouragement IMHO :)
[20:05] <Wes--> by crikey, I think I am finished the fs-base wiki doc
[20:05] <Wes--> (well, finished enough :) )
[20:07] <ondras> Wes--: well...do we say that somewhere? Perhaps I was reading the module spec poorly...
[20:08] <Wes--> ondras: Good question, I don't think we do. It might be an idea to put together a CommonJS FAQ that discusses stuff like that
[20:08] <ondras> it comes natural to me to mention it directly in modules spec
[20:12] <Wes--> ondras: well, THAT particular thing. But stuff like that shouldn't be buried either. What if somebody is rewriting a CommonJS program? They mighht not even look at the module spec if they didn't realize that their programs were also modules. Which they wouldn't know without reading the spec. But they might read a FAQ! :)
[20:13] <ondras> :P
[20:13] <ondras> okay
[20:13] <ondras> faq is generally a good thing
[20:13] <ondras> gotta love the faq.
[20:14] <ondras> dtach, zzz
[20:15] <Wes--> ondras: I have been putting together a general JavaScript pitfalls document, too. Lots of people jump in feet first, and that's okay, but sometimes they make bad decisions because they haven't spent oodles of time in thought around the subject. Which is too bad.
[20:15] <Wes--> (hey, have you read JavaScript: the good parts? )
[20:16] <ondras> no
[20:17] <Wes--> ondras: I highly recommend the book, it's a great two-evening read
[20:17] <ondras> I happened to find the good - and mostly the BAD - parts by trial and error :)
[20:17] <Wes--> (author is doug crockford)
[20:17] <ondras> I know
[20:18] * ondras works for company where 90% of js code heavily relied on eval() for some years .)
[20:18] <Wes--> ondras: http://code.google.com/p/gpsee/wiki/JavaScript_FAQ FWIW
[20:18] <Wes--> ah, nothing wrong with eval() if you are using it for the right reasons
[20:18] <Wes--> "work in progress"
[20:19] <ondras> I know
[20:19] <ondras> actually, I consider myself relatively eperienced with many js quirks
[20:20] <ondras> *experienced
[20:20] <Wes--> Me too. But there is still stuff in my document that surprised me. ;)
[20:21] <ondras> hehe
[20:22] <ondras> for instance, I was recently unpleasantly surprised by -2 % 7 :-(
[20:36] <jmerlin> regarding the 'this' in modules issue
[20:36] <jmerlin> can't you just make a new object, add the js script as a function of that object and call it so it gets its own clean 'this' and global scope (even for non-var variables) ?
[20:37] <Wes--> "even for non-var variables" explicitly contradicts ES3
[20:37] <Wes--> as for specifying a module loading implementation so that "this" behaves a particular way: why?
[20:39] <jmerlin> why not?
[20:39] <Wes--> jmerlin: You are saying "please implement something my way to satisfy my own whim"
[20:40] <Wes--> you need more of a justification than "why not"
[20:43] <jmerlin> to further the goal of complete segregation of modules except where it is explicitly desired behavior
[20:44] <Wes--> That does not solve that problem any more than making "this" be undefined does
[20:44] <Wes--> or, for that matter, just not using "this"
[20:44] <Wes--> (I happen to think it should be a syntax error outside of an instance method)
[20:45] <jmerlin> how else would you do a for-in over all global properties?
[20:46] <Wes--> jmerlin: ES3 does not guarantee that that is even possible
[20:46] <Wes--> it's a coincident side-effect of window IIUC
[20:47] <jmerlin> what about ES4 and ES5?
[20:49] <Wes--> jmerlin: ES4 is irrelevant, and I think ES5 is the same
[21:02] <isaacs> hey, ES5 geniuses, i've got a puzzle for you.
[21:02] <isaacs> i think i might have found something you can do with __proto__ but can't do with Object.create
[21:03] <isaacs> function Foo () {}; Foo.__proto__ = {bar : "baz"}; print(Foo.bar);
[21:03] <isaacs> ie, have a callable that extends a given object's members.
[21:04] <Wes--> jmerlin: BTW, turns out I'm wrong about global object, right from the horse's mouth:
[21:04] <Wes--> <brendan> Wes: it's an object
[21:04] <Wes--> <brendan> bound to |this|
[21:04] <Wes--> <brendan> setting new property this.x = 42 makes an enumerable x
[21:04] <Wes--> <brendan> order is not defined
[21:04] <Wes--> <brendan> de-facto standard is insertion order
[21:04] <Wes--> jmerlin: food for thought for sure
[21:19] <Dantman> isaacs, We knew about that before... Well, at least I knew about that already.
[21:19] <isaacs> turns out, though, that kinda breaks stuff anyway.
[21:20] <isaacs> you sort of usually want Function.apply to exist on a callable.
[21:20] <Dantman> One of my early implementations of MonkeyScript had function.inherit which set __proto__ on prototype and the function itself...
[21:20] <isaacs> but you could do myFun.__proto__ = Object.create(Function.prototype) and then add stuff to it
[21:21] <Dantman> ie: function A() {}; function B() {}; B.inherit(A);
[21:21] <Dantman> Then in addition to ((new B) instanceof A); there was the extra fun of: A.foo = function(); B.foo();
[21:21] <jmerlin> Wes--: i like the idea of the .global being a true "global" dumping ground with 'this' and local global scopes being separate for each module so no pollution can happen unintentionally
[21:22] <jmerlin> but that's just me
[21:23] <Wes--> jmerlin: I'm not particularly excited about being able to access the global object from a module without an externally-provided reference. The module-wide scope as an object, though, is interesting, if only because the global scope is defined.
[21:23] <Wes--> I'm curious as to what effect that would have on a variety of implementations
[21:24] <Wes--> That said, I still think 'this' outside of an instance method is more likely to confuse than help
[21:24] <Wes--> and, for that matter -- if you need it, you can provided it yourself
[23:36] <varmaa> is a commonjs module with a hyphen in it considered a bad module name b/c it's not camelCase? e.g. require('my-thing') should be require('myThing') instead?
[23:41] <ashb> varmaa: no i do my-thing personally
[23:41] <varmaa> woot!
[23:41] <varmaa> thanks
[23:41] <ashb> varmaa: but then i despise camelCase :D
[23:41] <varmaa> hehe
[23:42] <ashb> but no - a lot of modules are-dashed
[23:45] <varmaa> ashb: i also have a question about module.id and relative require paths... right now my loader's set up such that it's actually possible for a module 'A' to load another module 'B' via a relative path such that there is no actual "absolute path" to 'B'.
[23:46] <varmaa> which is odd and also means that there can't really be a module.id for it.
[23:46] <ashb> depends on what the engine decides to put for module.id
[23:46] <ashb> in hippo for isntance, module.id is a file:/// url
[23:46] <ashb> to get round that very problem :)
[23:46] <varmaa> ah, ok
[23:46] <varmaa> interesting
[23:47] <ashb> but that is sort of an edge case/hole in the spec, yes
[23:47] <varmaa> i had assumed doing such a thing would violate the def'n of require()
[23:47] <varmaa> ah ok
[23:47] <varmaa> cool, thanks!

 

 

Logs by date :