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

2009-12-02:

[0:00] <inimino> ah
[0:00] <inimino> http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
[0:01] <inimino> JohnnyL: something you were saying earlier reminded me of it
[0:01] <JohnnyL> anyway, thats all my concern was.
[0:01] <JohnnyL> So, it should be an easy fit.
[0:02] <JohnnyL> and afaics the best multi-* bits will go into the for structures.
[0:03] <JohnnyL> take the poll of a processor then assign it if it hasen't been that busy.
[0:03] <JohnnyL> Also, there are quite a few other adjustments made to js that can enhance multi-*.
[0:04] <JohnnyL> I am easily pegged at the client with some sites (like Dr. Dobbs).
[0:04] <JohnnyL> Have you ever heard of Dr Dobbs before inimino?
[0:05] <ashb> DDJ?
[0:06] <JohnnyL> ashb thats the one.
[0:06] <inimino> yes
[0:08] <inimino> JohnnyL: what do you mean by "pegged at the client"?
[0:10] <ashb> seriously. what is putting this it: xmlns:ns0="http://www.w3.org/XML/1998/namespace" ns0:space="preserve">
[0:10] <ashb> the ns0 bit. its not in the source xml document
[0:10] <MisterN> ashb: huh i think it should just emit xml:space="preserve" there
[0:11] <MisterN> xmlns:xml isn't ever necessary iirc
[0:11] <inimino> that is odd
[0:11] <MisterN> oh wait
[0:11] <MisterN> this isn't xml: this is XML Namespace
[0:11] <ashb> MisterN: yeah. i just need to find what is causing it
[0:11] <MisterN> http://www.w3.org/XML/1998/namespace <- look at the end of the url
[0:11] <ashb> 'The prefix "xml" cannot be bound to any namespace other than its usual namespace; neither can the namespace for "xml" be bound to any prefix other than "xml"'
[0:12] <inimino> heh
[0:12] <ashb> i just cant find what is causing this >_<
[0:13] <inimino> what processor are you using?
[0:13] <ashb> some POS ant script
[0:13] <ashb> http://old.nabble.com/build-problem-caused-by-xmlns-validation-td11360063.html
[0:13] <ashb> ah - that subject looked interesting
[0:14] <inimino> oh, wow, Ant and XSLT
[0:14] <inimino> hehe
[0:14] <ashb> yeah. its fully bat shit
[0:15] <ashb> XSLT to generate JS
[0:15] <inimino> have fun :P
[0:15] <ashb> HELP!
[0:15] <ashb> either with the code or get me some whisky
[0:15] * inimino hands ashb some whisky
[0:15] <ashb> Hi,
[0:15] <ashb> running into this problem again - still trying to build and use the test
[0:15] <ashb> suite. I have an updated build.xml file with an extra task to sort this
[0:15] <ashb> out - interested?
[0:16] <ashb> GAH. YES!. FUCK YOU HALLVORD R M STEEN
[0:16] * ashb loves XML. really
[0:16] <inimino> haha
[0:17] <inimino> nice try, XML still knows you are lying
[0:19] <ashb> ;_;
[0:20] <ashb> i dont know what these tests are even doing with the spec
[0:21] <inimino> where are they?
[0:21] <ashb> on the w3 site
[0:21] <ashb> but the unit tests themselves are all hand coded (in xml markup)
[0:22] <inimino> you know, I'd be tempted to write the whole thing with SAX or something
[0:22] <inimino> unless you just want to use XSLT for the pure masochism of it
[0:22] <ashb> there already is a XSLT that produces JSUnit html files
[0:22] <ashb> so hopefully once i get past this error
[0:22] <ashb> it shouldn't be that hard to just tweak that stylesheet
[0:23] <inimino> ah
[0:27] <ashb> ah so i think its trying to build a dom2.dtd for some reason
[0:29] <ashb> http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/DOM2-Core.zip is
[0:29] <ashb> is what its trying to build dtd's from
[0:43] <ashb> http://pastie.org/722792
[0:43] <ashb> that seems to be the template causing the issues
[0:45] <ashb> specifically the <xsl:apply-templates select="@*"/>
[0:46] <inimino> that's causing the ns0 stuff?
[0:46] <ashb> yeah
[0:47] <inimino> odd
[0:48] <ashb> little bit
[0:48] * ashb queries against http://dpawson.co.uk/xsl/
[0:49] <ashb> usually very good for xslt issues
[0:51] <inimino> isn't there an xsl:copy-of or something like that?
[0:51] <inimino> maybe XSLT 2.0
[0:51] <inimino> I seem to remember this crappy recursion stuff to get a simple copy went away at some point
[0:56] <ashb> inimino++
[0:56] <ashb> <xsl:copy-of select="@*"/> did the trick
[0:57] <inimino> nice
[0:59] <ashb> there we go - produce the shittihg JSuint html files now
[1:29] <JohnnyL> inimino are you a native english speaker? pegged=Reaching the absolute value of.
[1:30] <ashb> JohnnyL: not in very common usage tho
[1:31] <inimino> JohnnyL: yes, I am
[1:32] <inimino> JohnnyL: I'm familiar with that meaning of "pegged", it's the whole sentence I couldn't make sense of
[1:32] <inimino> I'm probably missing some context or something
[1:34] <JohnnyL> here is the exact usage according to dictionary.com: 19. to work or continue persistently or energetically: to peg away at a homework assignment.
[1:34] <JohnnyL> http://dictionary.reference.com/browse/pegged
[1:35] <inimino> ah, and by "client" I take it you meant "browser"?
[1:37] <JohnnyL> inimino precisely.
[1:38] <inimino> so then the meaning of your sentence was something like "I am easily kept spellbound for hours by such sites as Dr. Dobbs"
[1:38] <inimino> I am glad we got this cleared up
[1:53] <JohnnyL> Can't buy me love...
[2:24] <nrstott> for the record, I also find JohnnyLs pegged sentence confusing and I'm a native English speaker :)
[2:44] <JohnnyL> ashb yay, CLOS is interesting.
[2:46] <JohnnyL> nrstott go to ddj.com.
[5:29] <tlrobinson_> most of the comments on kris' ars article are bashing javascript
[5:29] * tlrobinson_ sighs
[6:08] <JohnnyL> tlrobinson url?
[6:08] <tlrobinson> http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars
[6:16] <JohnnyL> looks like a non-one sided report. which is what the news does(hopefully).
[14:55] <MisterN> tlrobinson: there are many positive comments too.
[14:57] <ondras> arguing on the internet ... (you know the rest)
[15:09] <MisterN> the article definitely brings a boost to the number of visitors to flusspferd.org
[15:14] <ondras> the same is true for v8cgi
[15:14] <ondras> hm, v8cgi truly needs a mascot
[15:15] <ashb> hippo!
[15:15] <ashb> jooiiiiiiiin usssssssss
[15:15] <ashb> >_>
[15:32] <ashb> you know what. module.file not existing is a pain.
[15:33] <ashb> it means i need to jump through some hoops to go 'read fomr the file x in the same dir'
[15:34] <Wes-> ashb: we need a module function to define module-relative paths
[15:34] <ashb> oh yeah the module.resource proposal thats been hinted at
[15:34] <Wes-> module.local("module.conf")
[15:34] <Wes-> yeah
[15:35] <ashb> .resource just needs to proxy to open doens't it
[15:38] <Wes-> ashb: IMO it needs to re-write the filename argument using *exactly* the same semantics as require(), then pass it to open
[15:38] <ashb> without the extension behaviour tho?
[15:39] <Wes-> ashb: Oh yeah
[15:39] <ashb> and isn't that basically all it does thats special?
[15:39] <Wes-> ashb: And without the narwhalian side effects
[15:39] <Wes-> ashb: Yes -- but it's a very special thing!!
[15:39] <Wes-> ashb: For starters, it's the basis for a package system
[15:39] <ashb> it is?
[15:40] <ashb> oh btw - it looks like we are leaning/i'm pushing towards require('package#module') syntax
[15:40] <ashb> rather than the 2 arg form
[15:44] <Wes-> ash: it is - you can do anything with this syntax, ie require("packageModule").resource("manifest").open()
[15:45] <Wes-> ashb: ugh
[15:45] <ashb> hmmm should probably have a mdoule.resource.resovle()
[15:45] <ashb> to pass the filename to things that dont accept open file handles
[15:45] <Wes-> ashb: that forces a package system into commonJS
[15:45] <Wes-> ashb: true
[15:46] <ashb> Wes-: it sort of does, but is that a bad thing? its still backwards-compat of a sort
[15:46] <Wes-> require("ccjsan").require("md5") -- ccjsan module can then load ../etc/manifest and then go looking for md5.js
[15:46] <ashb> its either an invalid module name if its checked or just a really really odd named one
[15:46] <Wes-> ashb: I'm a minimalist and believe in stepping stones
[15:47] <Wes-> ashb: UNIX philosophy has seldom steered me wrong in the long term
[15:47] <Wes-> "small pieces that each do one thing, and do it well"
[15:47] <ashb> i'll let you argue/talk with cdorn
[15:47] <Wes-> who is cdorn?
[15:47] <Wes-> oh, chris dorn
[15:47] <ashb> a narwhal guy
[15:47] <ashb> yeah
[15:47] <Wes-> I've completely tuned that out, because I'm not at all interested in that stuff right now
[15:48] <Wes-> WHICH btw, is kinda the point
[15:48] <ashb> i just dont want to end up with the holw TLD thing again
[15:48] <Wes-> require("cjspan") can be written ENTIRELY in fs-base and current require()
[15:48] <Wes-> top level domain?
[15:48] <ashb> mixed endian-ness
[15:49] <Wes-> clarify?
[15:49] <ashb> foo.org/bar vs org/foo/bar
[15:49] <Wes-> OIC
[15:49] <Wes-> mixed is stupid
[15:49] <Wes-> ca.page.gpsee.module.system makes sense
[15:49] <ashb> which the two arg form being thrown about would give: require('module','package').exportA
[15:49] <Wes-> AFAIC
[15:50] <Wes-> ashb: I think that's orthogonal to having the package system as a module
[15:50] <Wes-> require("cjspan").require("ca.page.crypto")
[15:50] <ashb> some people want it tied into things more
[15:51] <ashb> but actually - if you go with the module loader proposal, then you let things 'redefine' require i think
[15:52] <ashb> the module loader proposal also lets you define/pass other free top level variables to modules
[15:52] <ashb> which is useful for DSL-like purposes
[15:52] <Wes-> redefining require has security implications as well
[15:52] <ashb> sure does. useful tho :D
[15:53] <Wes-> see, the problem is that they are coming at this from a rhino-centric POV
[15:53] <Wes-> they don't have or want native modules
[15:53] <Wes-> so their require is basically load + eval
[15:53] <Wes-> which means they don't have an investment in how things work
[15:53] <Wes-> and foreign script can "replace" it
[15:54] <Wes-> Imagine somebody trying to graft a module system into flusspferd by rewriting require() from script?
[15:54] <ashb> you'd have to proxy to the original require
[15:54] <Wes-> yeah
[15:54] <ashb> require('vm').require
[15:54] <ashb> or some such
[15:55] <Wes-> the other thing is - *why* does the language standard have to encompass the package system?
[15:55] <Wes-> There is no *advantage* to doing that
[15:55] <Wes-> separating packages from modules is a *good* thing
[15:56] <ashb> take it up with them :)
[15:56] <Wes-> glomming them together reduces code reuse (since require() is system specific)
[15:56] <ashb> i'm kind of ambivelent
[15:56] <Wes-> ashb: I already did, they don't want to listen
[15:56] <Wes-> frankly, if require() takes on package semantics, I'll just drop CommonJS compatibility
[15:57] <Wes-> It's more important to me to have flexibility with my own local projects than it is to market a CommonJS product
[15:57] <ashb> so conceptually packages are just groups of modules and possibly associated resources, yes?
[15:57] <Wes-> ashb: right
[15:57] <Wes-> But I don't want to have to put that logic in the module loader
[15:58] <Wes-> Right now, require(), fs-base, and binary define "what is commonjs"
[15:58] <ashb> the last proposal i saw maintained module behaviour
[15:58] <Wes-> ashb: I see what I eat != I eat what I see
[15:58] <Wes-> CommonJS should be looking at *building* on existing stepping stones
[15:58] <ashb> if you are in package y require('x') would look for it only in the current package
[15:59] <Wes-> I see adding require-must-do-packages as replacing a building block that I'm not interested in replacing
[15:59] <ashb> hmmm there is that.
[15:59] <ashb> i would be entierly happy with the package manager being just a module you load
[15:59] <ashb> much like gems
[15:59] <Wes-> but, adding a packages module -- that's constructive!
[16:00] <ashb> they seemed to think doing that would make packages 2nd class citizens then
[16:00] <Wes-> ....I don't even understand that point
[16:00] <ashb> i didn't quite get it either i have to admit
[16:00] <Wes-> that packages are less important that programs? of course they are
[16:01] <ashb> brb. getting some tea
[16:01] * Wes- runs for coffee
[16:05] <ashb> right then
[16:06] <ashb> Wes-: so if you are happy with the mdoue loader proposal with lets you do something like:
[16:06] <ashb> require.loader('x', { foo: bar })
[16:07] <ashb> and have foo be available as a free-variable in the module scope
[16:07] <ashb> then require = require('cjspan').require
[16:07] <ashb> and then anything required that way gets the package manager require
[16:07] <ashb> and that require just does kernel_require.loader(... {require: pkgMgrRequire})
[16:08] <Wes-> Sorry, I think I lost you at require.loader
[16:08] <Wes-> you're talking here about re-writing require as an implementation technique?
[16:09] <ashb> letting a module replace it 'transparently'
[16:09] <ashb> oh the spec i'm thinking of doesn't really illustrate the point
[16:09] <ashb> http://wiki.commonjs.org/wiki/Modules/Loaders/B
[16:09] <ashb> s/spec/proposal/
[16:09] <Wes-> ashb: Within the scope of that module, and that module only, that's fine
[16:10] <ashb> not happy with it propgating to anything that required by it?
[16:10] <ashb> (which is how ruby gems works)
[16:11] <Wes-> No - how would that play with sandboxes?
[16:11] <Wes-> also, fwiw, would break gpsee, but maybe I could figure out another solution
[16:11] <ashb> because of the mdouel-scope unloading?
[16:11] <Wes-> require object actually has private prop which tells me what the module is
[16:11] <Wes-> so that I can do module-relative requires
[16:11] <ashb> oh hmm. so does our require actually.
[16:12] <ashb> but so long as it just searches for the module differently and then proxies to the proper require i think it should work
[16:12] <Wes-> it also means that you need to allow a module to access and write to the global object
[16:13] <ashb> oh?
[16:13] <Wes-> Or are you only talking about re-writing require() for its descendents?
[16:13] <ashb> yeah jsut for anything required through that require
[16:13] <Wes-> Hmm
[16:14] <Wes-> FWIW my smell-test is going off but I can't put my finger on the problem
[16:14] <ashb> fair enough. i've been playing that card a lot lately. So i can respect it
[16:17] <ashb> Wes-: basically i'm just trying to find a solution that doesn't end u pealving you behind, cos i think that would be bad
[16:17] <ashb> s/ p/p /
[16:18] <Wes-> ashb: Yeah, I'm not a fan of "i'm taking my toys home" politics either, but I can't be turning around and re-implementing stuff I don't need to just maintain somebody else's check-list
[16:18] <Wes-> and implementing require() is pretty much equivalent to "do you support commonjs or not"
[16:18] <ashb> yeah
[16:26] <ashb> Wes-: i've often wondered just why with is so slow.
[16:26] <ashb> conceptually i cant see why it should be any slower than just a closure
[16:37] <Wes-> ashb: Have to admit, I'm kinda with you there
[16:37] <Wes-> but the spidermonkey guys really hate on with()
[16:37] <Wes-> I know it causes you to fall off the trace, for starters
[16:37] <ashb> and again - i dont see why it should
[16:37] <Wes-> but that's in the chicken-egg neighbourhood
[16:37] <Wes-> yeah
[16:38] <Wes-> scopes must not be linked lists or something
[16:38] <Wes-> 'cause if they were, it'd just be an extra node for a little while, you'd think
[16:39] <MisterN> how about making require('./X') always use the same loader as the current module?
[16:39] <ashb> thats bascially what i was suggesting, just doing it in a different way
[16:41] <Wes-> well, can you already do that with current require:
[16:41] <Wes-> require = function() new_require() { };
[16:41] <Wes-> at the top of your module
[16:41] <ashb> yeah its just a pain to do that in every module >_>
[16:42] <Wes-> yes, so the next thing that happens is that people will want to re-write the global require
[16:42] <Wes-> hmm
[16:43] <Wes-> Somebody wanna remind me what packages "do", besides
[16:43] <Wes-> 1) manage dependencies
[16:43] <Wes-> 2) get loaded from some place other than the module path
[16:43] <Wes-> 3) collect multiple modules under a common directory
[16:43] <Wes-> ?
[16:44] <ashb> there might be a few other things. but that is largely it i think
[16:44] <Wes-> 1) is the job of the package manager (apt-get)
[16:44] <ashb> narhwal has some kind of crazy preloader or some such
[16:44] <Wes-> 2) Is a minor tweak somewhere
[16:44] <ashb> 1) apt sucks. or at least debian apckages do
[16:44] <Wes-> 3) is already implemented or module.resource
[16:44] <Wes-> apt - just an example
[16:44] <Wes-> could have have said "cpan"
[16:44] <Wes-> it's still not the job of the module loader
[16:45] <ashb> ah - we have different views on manage
[16:45] <ashb> manged is just 'a defined and introspectable way of declaring them' and yes, thats not part of the package loader
[16:46] <ashb> but is part of the whole package system
[16:47] * Wes- nods
[16:48] <Wes-> I still think it would be excellent, awesome, and appropriate if packages from start-to-finish could be implemented with fs-base, current-require, pure-javascript, and a wget-like module
[16:49] <Wes-> we're *so close* to having a system that hangs together that changing basic building blocks seems insane to me
[16:49] <Wes-> has there been a system.system("cat /etc/passwd") proposal or anything yet?
[16:49] <ashb> dont think so. thats more an os or a posix module i think tho
[16:50] <Wes-> *nod*
[16:50] <Wes-> BTW, one smell receptor just fired:
[16:50] <Wes-> proxying require() means that sandboxes environments that proxy require() could get entertaining
[16:50] <Wes-> behaviour would change based on when you proxied require()
[16:51] <ashb> hmmmm
[16:59] <ashb> k anyone who wan'ts to use my DOM tests is going to need mdoule.resource
[17:00] <ashb> Wes-: i guess the leading './' on module.resource is optional/implicit
[17:01] <Wes-> ashb: seems reasonable. Should definitely support ../
[17:01] <Wes-> are you returning a Path, or what?
[17:02] <ashb> a Path object? that doesn't exist? ;)
[17:15] <Wes-> ashb: Of course! That's never stopped you before.
[17:15] <ashb> lies!
[18:31] <ondras> oops
[18:31] <ondras> bad code posted to the thread
[18:31] <ondras> .)
[18:32] <ashb> ondras: yeah gonna say. that wont work :)
[18:33] <ondras> it *will* pass all the data in, though :)
[18:33] <ashb> sure
[18:33] <ondras> but the naming is far from optimal
[18:33] <ashb> it wont make them available as free variables tho
[18:34] <ondras> well, "arguments" is a kind of free variable, but.. :-(
[18:37] <deanlandolt> what is the status of the custom loaders stuff? isn't one of the goals of that idea to bring in free variables?
[18:37] <ashb> yeah
[18:37] <ashb> status is very very not specd
[18:38] <deanlandolt> what about the require wrapping you were talking about earlier? wouldn't that make this pretty easy too?
[18:39] <ashb> that was based on the unspeced modue loaders :)
[18:39] <deanlandolt> is there something fundamentally impossible about having any number of different require wrappers in a module you could import and wrap require in your current context to do this special stuff?
[18:40] <deanlandolt> it seems like there could be a requiredecorators package that people could have as a dependency that can do all this fancy stuff without f'ing up the semantics of require
[18:40] <deanlandolt> it's not /illegal/ to replace require is it (like it is to replace exports)?
[18:41] <ashb> its not illegal to replace exports
[18:41] <ashb> it just wont change the exports from the module
[18:41] <deanlandolt> err, against the spec (in a bad way at least)
[18:41] <inimino> ashb: variable binding isn't statically analyzable when enclosed by with
[18:42] <inimino> (re: something you said a while ago)
[18:42] <deanlandolt> ashb: okay, so it's discouraged at least...is wrapping require discouraged as well? i've never heard that
[18:42] <deanlandolt> inimino: him and Wes- knew...iirc they just don't know /why/ (i'd love to know too)
[18:42] <ashb> deanlandolt: never come up before
[18:42] <ashb> inimino: but its really really useful :(
[18:43] <inimino> deanlandolt: I'll give an example
[18:48] <inimino> var x,y,i,a for(i=1;i<a.length;i++){ with(o){ x = Math.max(a[i], a[i-1]); y = Math.min(a[i],a[i-1]); f(x,y) }}
[18:49] <deanlandolt> inimino: where'd o come from?
[18:50] <inimino> deanlandolt: it's just something from some other part of the program
[18:50] <inimino> I should have added it to my var statement for clarity
[18:50] <deanlandolt> that's what i thought...just wondering
[18:50] <deanlandolt> and there's no way to know while JIT'ing what o is?
[18:51] <ashb> in some cases yeah
[18:51] <deanlandolt> o could change out from under the analysis i guess...is that the issue?
[18:51] <inimino> the interesting thing is that now you can't know what Math object to use
[18:51] <inimino> without looking it up each time you go through the loop
[18:51] <deanlandolt> i didn't think that was a JIT issue as much as the /other/ reason require's frowned upon
[18:51] <deanlandolt> oh, okay
[18:52] <deanlandolt> makes more sense now...i think i actually understand (i'm a little surprised, frankly)
[18:52] <inimino> f could have added a Math property to o
[18:52] <ashb> you can optimize it a bit by tracking shape chanes of hte object
[18:53] <inimino> there's nothing else in the language that can change things out from under you in quite that way
[18:54] <ashb> not to the same degree, no
[19:15] <ashb> Wes-: i wonder just how much trouble we are asking for ot use the debug api and get old of the var obj and just start messing about
[19:30] <- *graboth* Full name of my home town:
[19:34] <Dantman> deanlandolt, ^_^ Remember, in the magical world of JavaScript, even constants aren't constant, we have fancy scoping: const MYCONST = 5; (function() { var MYCONST = 6; print(MYCONST); })();
[19:35] <deanlandolt> Dantman: and?
[19:35] <Wes-> ashb: quite a bit, I suspect, as the perf oriented folks have been making noises about making that not-actually-an-object
[19:35] <Dantman> (function() { var require = ...; require(notamodule); })(); ;) you can do whatever the hell you want to require
[19:36] <deanlandolt> oh, i know
[19:36] <Dantman> ^_^ And modules are supposed to have implied functional scope...
[19:36] <ashb> Wes-: hmm. surely the debug api will let you change things anyway tho?
[19:36] <deanlandolt> i was just asking if there's some unwritten assumptions in SecurableModules that means we shouldn't
[19:36] <deanlandolt> (kinda like how you shouldn't replace exports)
[19:37] <Wes-> ashb: Don't count on it. The debugging API is not considered stable like the jsapi
[19:37] <ashb> i mean in generaly purposes a debugger needs to at least read the closed over variables doesn't it?
[19:37] <ashb> and most of them let you alter it anyway
[19:38] <ashb> so it might not be a JSObject* in strictest sense, but shouldn't the API have those features?
[19:38] <Wes-> ashb: presumably, yes, but that doesn't mean you'll be able to read them as a JSObject *
[19:38] <Dantman> Well, I don't think there are any unwritten assumptions in the spec... But there are probably assumptions made by people writing modules and whatnot in CommonJS... Like, require should be module's require and modules will break if you change that variable they inherit
[19:38] <Wes-> deanlandolt: I could be wrong, but I don't think "don't replace exports" is unwritten
[19:39] <ashb> you can replace it. it just doesn't replace the actualyl exports
[19:39] <deanlandolt> Wes-: actually, i don't think you're wrong...it's just very clear
[19:40] <ashb> and as such, if you know that its perfectly crumulent
[19:41] <deanlandolt> ashb: wtf? crumulent?
[19:41] <deanlandolt> google tells me cromulent means Fine, acceptable, normal...
[19:41] <deanlandolt> where the hell did that word come from?!
[19:42] <ashb> simpsons
[19:42] <inimino> The Simpsons
[19:42] <Wes-> deanlandolt: it's from the Simpsons - they have been embiggening the English lexicon
[19:42] <deanlandolt> heh...yeah, just figuring that out now
[19:42] <deanlandolt> but it's in freakin' dictionary? you've got to be kidding -- they've got to put a stop to this
[19:43] <deanlandolt> i know they say english is an "open" language but seriously, i can't keep up
[19:44] <Wes-> deanlandolt: just wait 'till microsoft implements their own version
[19:45] <deanlandolt> have you read some of their marketing material?!
[19:45] <Wes-> deanlandolt: it all seemed perfectly cromulent to me
[19:45] <deanlandolt> :)
[21:05] <ashb> kriskowal: how is mandating a string litteral to require() even enforceable?
[21:05] <kriskowal> in most places it is not.
[21:05] <kriskowal> why is it important that it be enforceable? ;-)
[21:06] <ashb> cos you sait it shouldn't be allowed :)
[21:06] <ashb> (said
[21:06] <kriskowal> static analysis can enforce it.
[21:06] <kriskowal> the question is who's doing the allowing
[21:06] <ashb> its only the one tool that needs that isn't it?
[21:06] <ashb> and such shouldn't that tool enforce it
[21:06] <ashb> (where tool = the async preloader)
[21:08] <kriskowal> i'm asking for permission for any of us to look at a piece of code and say: this program will not work in browsers. it should therefore not be included in a commonjs standard library. it has a bug.
[21:09] <kriskowal> this can be automated with static analysis. it is not important that it be enforced at run time. if it has a non-string literal in a require, it will result in race conditions.
[21:09] <kriskowal> point of fact: race conditions are bugs, but it's not possible to enforce them out of existence.
[21:10] <ashb> there are lots of other factors that would make code not work in a browser. but I took that message to mean "we should specify that require() will only ever take a string literal"
[21:11] <ashb> which i am never going to agree too
[21:12] <ashb> hmmm the other thing - require.loader: does it still have the same exports constraints as require()?
[21:17] <Wes-> require() should be statically-allowable to take module.id as well as a string literal
[21:17] <Wes-> and static analysis should prevent modification of module.id
[21:17] <ashb> module.id is defined as readonly
[21:17] <ashb> but the module object is changeable i guess
[21:17] <Wes-> this fixes my binary/D toString comments
[21:18] <Wes-> ashb: right, and changing module would be a race hole there
[21:18] <ashb> also can't pass module.id easily between modules
[21:18] <ashb> tbh i see it more as the case: if the user hasn't declared a preload, its a bug in their code or in a module they use. the either get and error or get a sync xhr request.
[21:45] <hannesw_> we have a lot of dynamic use of require() in helma-ng
[21:46] <MisterN> hannesw_: why?
[21:46] <hannesw_> for example, our JSGI handler takes a module and property name to lookup the JSGI app
[21:46] <hannesw_> http://helma-doc.appspot.com/helma/jsgi
[21:46] <hannesw_> we couldn't do that if require could only take string literals
[21:46] <MisterN> hannesw_: easy, change it to take an object instead of a module name. that's more flexible anyways.
[21:47] <hannesw_> no, it's not
[21:48] <hannesw_> a module id can be loaded dynamically, the caller doesn't have to load/provide the module
[21:48] <hannesw_> for example, all this stuff in helma-ng is auto-reloading
[21:48] <hannesw_> because it uses module names, not module objects
[21:49] <MisterN> hmm.
[21:49] <MisterN> hannesw_: so the reloading that i once talked about on the list is coming back?
[21:50] <hannesw_> well i see no problem with saying "if you want it to run in the browser, you're restricted to string literals in require()"
[21:51] <hannesw_> MisterN: I can't remember, when was that?
[21:51] <hannesw_> reloading has always been a core feature of helma-ng (and helma1 before that)
[21:51] <MisterN> months ago
[21:51] <MisterN> hannesw_: i also haven't read the list recently
[21:51] <MisterN> reloading was said to be unsafe in javascript.
[21:53] <hannesw_> it's mostly safe in helma-ng. there may be some corner cases, but usually running code never notices a reload
[22:10] <ashb> hannesw_: i'm against it too
[22:11] <hannesw_> I think it's ok as additional requirement for browser-targeted modules
[22:11] <ashb> i prefer the 'if you do this and don't otherwise pre-declare the module for preload you get X happen'
[22:12] <ashb> where X is either runtime throw, compile time thorw from the static anylizer, or a sync XHR request to laod it
[22:17] <MisterN> optimally would be configurable
[22:17] <ashb> i dont have a problem with the restriction for certain cases. restricting all cases just for this one case i dont like
[22:18] <MisterN> certainly.
[22:33] <tlrobinson_> i actually have a couple dynamic uses of require in jack
[22:33] <tlrobinson_> i would be fine with a SHOULD clause
[22:33] <tlrobinson_> and have the static analyzer throw warnings/errors
[22:33] <ashb> should itself is a bit strong. it should just explain why
[22:34] <ashb> http://redmine.flusspferd.org/issues/show/177 btw
[22:34] <ashb> we're implementing module.resource in hippo
[22:34] <ashb> cos i need it
[22:35] <ashb> comments on that API?
[22:35] <ashb> (such as it is)
[22:36] <tlrobinson_> i like it
[22:36] <ashb> it just saves me munging module.uri everytime i need the exact same feature
[22:36] <tlrobinson_> do we have a way to get the module object of other modules?
[22:36] <tlrobinson_> / should we?
[22:36] <ashb> not currently unless they give it to you, or they are the main
[22:36] <ashb> i've thought about it. i'm not sure
[22:37] <ashb> it would likely be YARP (yet another require property)
[22:37] <ashb> i wonder if we shouldn't move some of the properties from require into a kernel / core module?
[22:40] <kriskowal> ashb, i'm recommending module.resource(path):Path
[22:41] <kriskowal> module.resource(path).toString() would be the resolve case, and module.resource(path).open() would give you the stream case.
[22:41] <ashb> ah. we've not yet done the path object
[22:42] <kriskowal> that's fine. you could use that API and do it with path objects later, if at all
[22:42] <ashb> yeah. probably will at some point
[22:42] <ashb> need to talk about some of the things in the non fs-base proposal too
[22:42] <ashb> probably not until the new year tho
[22:43] <ashb> whats the status of narwhal's impl of fs-base btw?
[22:44] <kriskowal> we don't have one yet, but it won't be much trouble
[22:44] <ashb> most of it is just alias fs-base to load your fs module isn't it
[22:44] <ashb> i guess the permissions might be the only bit that isn't done yet
[22:45] <ashb> (i know we haven't obthered with that yet
[22:45] <kriskowal> yeah, our file-engine module is fs-base with different names.
[22:48] <kriskowal> we need a todo list for module system amendments
[22:48] <ashb> and thats a superset of whats in fs-base?
[22:48] <ashb> or rather doesn't have anything conflicting?
[22:48] <kriskowal> no, it's almost the same.
[22:48] <kriskowal> it will have to be copied and edited.
[22:52] <ashb> kriskowal: re todo: you mean spec extenion for things like module.resource?
[22:53] <kriskowal> well, we need proposals for that and require.async. I've made a list of proposals that need to be made
[22:53] <kriskowal> i'm sure we've discussed other amendments that need to be on that list too
[22:53] <ashb> oh - and my earlier question about require.loader.load and exports singletons
[22:53] <kriskowal> someone prolly ought to add a page for the "include/import" discussion, although i'm not pursuing it
[22:54] <ashb> kriskowal: ah both of those are in the http://wiki.commonjs.org/wiki/Modules proposals section already
[22:54] <kriskowal> oh. exports doesn't exist on that level.
[22:54] <kriskowal> yeah, i just posted the edit
[22:54] <ashb> ah :)
[22:54] <kriskowal> loader is not required to have singletons, but it can for module factory functions
[22:55] <kriskowal> but it can also reload if a file has changed
[22:55] <ashb> i was just wondering what it would do if you pass it different arguments
[22:55] <kriskowal> reload implicitly
[22:55] <ashb> but if there's no singleton exports requirment, then its not an issue
[22:55] <kriskowal> on the factory?
[22:55] <ashb> yeah
[22:55] <kriskowal> load(id)(different args)?
[22:55] <ashb> yup
[22:56] <kriskowal> well, one of those args is supposed to be your singleton exports if you're calling it from a sandbox, so no issue as far as i can tell
[22:56] <ashb> oh yeah, fair point :)
[22:58] <kriskowal> ah, yeah. we also need to make a note to fix the module identifier domain
[22:58] <ashb> ?
[22:58] <ashb> file:// thing?
[23:00] <kriskowal> camelCase thing
[23:01] <kriskowal> we need proposals that fix that issue
[23:01] <ashb> oh yes
[23:02] <kriskowal> i know you took initiative on that before and i got in your way, but i agree it still needs to get fixed
[23:02] <ashb> someone else complained evne more loudly than you

 

 

Logs by date :