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

2009-10-29:

[0:54] * Dantman|sick is surprised that none of the memcopy people made any complaints about JSGI
[1:19] <tlrobinson> memcopy?
[1:22] <Dantman|sick> Or maybe I just need more thought on it
[1:23] * Dantman|sick wishes his home network was as stable as work
[1:35] <Dantman|sick> Maybe I should just look at the various use cases in JSGI (normal use, streaming files, async, middleware, etc...) and draft up some examples of them in forEach and streaming to look at
[1:42] <tlrobinson> Dantman|sick: i don't know what problem yiu're talking about
[1:48] <Dantman|sick> Creation of unnecessary ByteStrings, transcoding inefficiency?
[1:58] <deanlandolt_> Dantman|sick: if you want to avoid creating unnecessary ByteStrings, don't use middleware that modifies the response body
[1:59] <Dantman|sick> No, not that
[1:59] <deanlandolt_> where's the problem?
[2:02] <Dantman|sick> Something about character transcoding and needing to create a superfluous ByteString from a ByteArray instead of directly moving data from the ByteArray to the stream JSGI is writing to
[2:07] <tlrobinson> Dantman|sick: at least in narwhal you could hack it by returning a wrapper object the used the same backing buffer
[2:08] <deanlandolt_> hmmm
[2:08] <tlrobinson> something like { _ba : originalByteArray, toByteString : function() { return new ByteString(this._ba._bytes, this._ba._offset, this._ba._length); } }
[2:09] <tlrobinson> but you'd have to be sure the buffer isn't changed before its transmitted
[3:34] <RayMorgan> In this spec: http://wiki.commonjs.org/wiki/JSGI/Level0/A ... what is the definition of the error stream? is it the text stream from: http://wiki.commonjs.org/wiki/IO/A? or something else?
[3:43] <tlrobinson> RayMorgan: yeah it will be the commonjs text output stream. that IO/A proposal isn't final
[3:44] <tlrobinson> alternatively we could just specify a few methods that it should respond to. same with the input
[4:04] <isaacs> ashb: Yes, I did want to play! thanks for the link
[4:04] * isaacs has been busy with yuiconf all day
[9:13] <olivvv> just curious, what are the differences between aptana cloud and joyent smart plateform ?
[9:16] <MisterN> both aren't commonjs :)
[9:19] <ashb> i should really get juice running on smart sincei know the guy in charge of it ;)
[9:21] <evilstreak> maybe get a few more versions released first? :P
[9:22] <ashb> naaah
[9:23] <ashb> wow brended is crazy. narcissus is JS interpreter in JS
[9:24] <ashb> *brendan (eich)
[9:24] <Dantman|sick> ^_^ Oh right, there was a bug somewhere in the narcisist's parser
[9:27] <ashb> heh
[9:34] <ashb> okay i can't actually seem to get narcissus working properly out side of js shell
[9:40] <MisterN> can narcissus run itself? :D
[9:42] <simono> f
[9:46] <Dantman|sick> MisterN, only when it's staring at it's own pool
[13:28] <angelm> hi ondras, i'm angel from the v8cgi google group
[13:40] <ondras> angelm: hi
[13:58] <angelm> i hang on the problem with my debian and failing file-write permissions
[13:58] <angelm> the apache error.log got has no informations about
[13:58] <ondras> okay
[13:58] <ondras> so, what is your apache config and how does your script look like?
[13:59] <angelm> hm
[13:59] <angelm> i try to create a image file and got the error: Error: /home/www/web0/html/labs/v8cgi/captcha/JxCaptcha.jx:81: Cannot open file
[14:00] <angelm> the same is happening with scqlite files
[14:00] <ondras> okay, show line #81 of JxCaptcha.jx
[14:00] <ondras> resp. what is the requested filename (with complete path)?
[14:01] <angelm> image.save(Image.PNG, new File('captcha.png'));
[14:01] <angelm> the path could be the problem?
[14:03] <angelm> will try with system.getcwd()
[14:04] <ondras> well
[14:04] <ondras> this file is executed with apache module?
[14:05] <ondras> ah, I see - use image.save(Image.PNG, "filename.png")
[14:05] <ondras> let me know what are the results
[14:06] <angelm> ok
[14:07] <angelm> tryed: var file = system.getcwd() + '/captcha.png';
[14:07] <angelm> the error occures
[14:07] <angelm> tried with "/capcha.png" and "./captcha.png" the same
[14:08] <ondras> so
[14:08] <ondras> now
[14:08] <ondras> image.save(Image.PNG, "/tmp/image.png")
[14:10] <angelm> something happens: Error: undefined:2: SyntaxError: Unexpected token ILLEGAL
[14:10] <angelm> maybe thats another error ill check the tmp directory
[14:11] <angelm> yes there is an image.png :)
[14:11] <ondras> fine
[14:11] <ondras> so
[14:11] <ondras> note that apache process runs as a different user
[14:11] <ondras> most probably as "www-data"
[14:12] <ondras> so, this user must have rights to access the directory in which you want to create the image
[14:13] <angelm> hm i can try to give some rights to the captcha-special directory?
[14:13] <ondras> it would be best to learn about unix permission system first
[14:13] <angelm> i to all the time
[14:13] <angelm> i do
[14:15] <angelm> you're in right. i gave to the folder the write permission and the file can be created
[14:15] <ondras> :)
[14:15] <ondras> cool
[14:16] <angelm> strange, i did'n now the problem, cos i cant remember to do that ever in php... hm?
[14:17] <ondras> php will have the same problem I guess
[14:18] <angelm> one moment...
[14:22] <angelm> the folder has 755 and the file 744. and file is written. this depends on the suphp-setting, i have unlocked the permissions
[14:23] <angelm> in normal case, the php-file needs 777 permissions
[14:23] <angelm> or needed before suphp
[14:23] <evilstreak> 777 is not a good idea
[14:24] <evilstreak> (in general terms)
[14:25] <ondras> writing to filesystem with php is not a good idea in general terms
[14:26] <evilstreak> heh
[14:28] <angelm> why it is not a good idea...
[14:28] <ondras> because every other user can manipulate these files
[14:28] <evilstreak> because you are giving permissions to any process on the system to edit the files
[14:29] <evilstreak> much better to chown the file to the correct user and/or group and give write permissions for that only
[14:29] <evilstreak> which I imagine is what suphp does?
[14:29] <ondras> even if you restrict the access only to the www-data group, any other user can create a php script which will run under www-data gid...
[14:30] <ondras> accessing the fs with anything related to apache is risky
[14:31] <simono> anybody got subphp link?
[14:32] <simono> got it http://www.suphp.org/
[14:33] <angelm> ok on bigger projects, communities, i understand to be carefully with permissions and to delimit them to areas as much as possible
[14:33] <ondras> well, the suphp solution looks nice
[14:34] <simono> i wonder if any big ones use it
[14:37] <angelm> was automatically installed on my vserver while an upgrade, this tool brings me to spend some days in learning linux...
[14:37] <Wes--> php never needs 777, unless your hosting platform is BADLY broken
[14:38] <simono> i really wonder why i never heard of this subphp, this seems to solve the shared hosting.
[14:39] <Wes--> simono: I don't know about suphp, but that can be solved in the general case as an apache module anyhow
[14:39] <Wes--> that way, you get su'd ssi, commonjs, cgi, whatever
[14:39] <angelm> yes, yes 755 to execute and 744 to write
[14:39] <simono> Wes--: what apache module?
[14:40] <Wes--> simono: Don't know if there is a public one, I wrote one about 10 years ago for apache 1.3, it was pretty trivial
[14:40] <simono> then i wonder why no one deploys / writes it again...
[14:41] <Wes--> Maybe people don't want to give their web hosting clients actual unix accounts?
[14:41] <Wes--> We wound up migrating away from that approach and virtualized the entire filesystem API and AAA
[14:41] <Wes--> (again as apache 1.3 modules)
[14:41] <simono> the php community came up with this whole safemode disaster to get around the shared hosting problem
[14:43] <simono> well that seems like overkill.. i'd rather use suphp :)
[14:44] <ondras> i'd rather use database.
[14:45] <Wes--> simono: any reason why you couldn't use suEXEC?
[14:45] <Wes--> as for overkill, we also had other requirements
[14:45] * simono reading up on that
[14:46] <Wes--> but a big one was "not leak unix users to vhost accounts"
[14:47] <simono> suexec doesnt work for php
[14:47] <simono> if its dyn loaded
[14:48] <Wes--> Really? That's unfortunate/silly.
[14:48] <simono> okay okay i could run them as cgi and then suexec would help.. anyways i wont touch those php-servers again anytime soon ;)
[14:48] <Wes--> simono: It's not just a PHP question, though, I'm interested in parity solutions for CommonJS, which is why it's useful to re-think "does this make sense"? :)
[14:50] <simono> oh it is interesting. not so much suexec.. and not so much for me (no shared hosting).. but carry on :)
[14:51] <Wes--> simono: Some day, I intend to let users run arbitary CommonJS code on apache. The sandboxing will be entertaining.
[14:53] <simono> :)
[14:53] <JohnnyL> will there be an option to list source code from an interpreter in cjs?
[14:54] <Wes--> JohnnyL: probably not, although at least mozilla engines will at least let you call toSource() on functions and stuff
[14:56] <JohnnyL> Wes- ok
[15:06] <Wes--> johnresig: ping
[15:07] <evilstreak> we need to get some unit tests set up for Juice (both to test the framework itself, and for testing apps written in it). Therefore, what's the state of your changes to make QUnit compatible with CommonJS?
[15:08] <evilstreak> (so we can use the same framework for testing stuff on both client and server, eventually)
[19:13] <erikg> how was the securable modules proposal ratified?
[19:16] <Wes--> money. lots of money.
[19:16] <kriskowal> yeah. greased some palms
[19:16] <Wes--> would you like another proposal ratified? :)
[19:16] <erikg> i have a nickle
[19:17] <kriskowal> that or the two week discussion comprising 600 or so messages followed by a lot of +1's
[19:17] <erikg> er, nickel!
[19:17] <erikg> kriskowal: i guess i'm confused about the process
[19:17] <kriskowal> the whole discussion is pretty well documented?let me pull up a link
[19:17] <erikg> enough +1's equal ratification?
[19:17] <kriskowal> that's pretty vague
[19:18] <erikg> kriskowal: thanks
[19:18] <kriskowal> yeah, our process is a bit loose. we tried to remain open to encourage people to step forward
[19:19] * erikg is wishing he started following the ml sooner
[19:19] <erikg> kriskowal: i think that's excellent
[19:19] <kriskowal> http://groups.google.com/group/commonjs/browse_thread/thread/d2dc85a2725992be
[19:21] <kriskowal> erikg, did you have a concern?
[19:22] <kriskowal> just yesterday, i do not recall who, brought up runjs as a "competing" proposal
[19:23] <kriszyp> jburke, I think
[19:23] <kriskowal> ah, yeah.
[19:24] <erikg> kriskowal: i do have some concerns
[19:24] <erikg> but mosly they boil down to "what did people think was wrong with the pythonic modules proposal?"
[19:24] <kriskowal> there are not many differences?
[19:24] <erikg> securablemodules introduces some keywords...
[19:24] <Wes--> personally, I'm afraid of snakes
[19:25] <kriskowal> in fact, i think helmang is compatible with both, along with old versions of chiron
[19:25] <Wes--> in all seriousness, we want namespacing
[19:25] <erikg> kriskowal: interesting
[19:25] <kriskowal> the principle distinction is the omission of "include" and "import" which break lexical analyzability
[19:26] <kriskowal> which is important to security people
[19:26] <Wes--> kriskowal: right, *whatever* we do has to be a function call, anyhow - otherwise you have to modify the language itself
[19:26] <erikg> Wes--: so i read that the pythonic proposal includes scoping: http://wiki.commonjs.org/wiki/Modules/PythonicModules#Every_module_has_its_own_scope
[19:27] <kriskowal> erikg i don't think "keyword" means what you think it means ;-)
[19:27] <erikg> kriskowal: 'defacto'
[19:27] <kriskowal> it does add three "free variables"
[19:27] <kriskowal> however, so does the pythonic modules proposal
[19:27] <kriskowal> it in fact adds two more.
[19:28] <erikg> kriskowal: i'm not finding them
[19:28] <erikg> but i'm only reading the wiki
[19:28] <Wes--> free variables leaking out from the module are always a mistake IMO
[19:28] <kriskowal> well, let me refresh my memory
[19:28] <Wes--> ADTs need to be able to preserve private data with some kind of enforcement
[19:28] <kriskowal> erikg, first, what "keywords" do you mean? "require", "exports", and "module" are the "free variables" i think you're referring to.
[19:30] <erikg> we are talking about free variables, as this isn't about adding keywords.
[19:30] <erikg> excuse my confused use of the word
[19:30] <erikg> exports specifically
[19:30] <kriskowal> ah, exports
[19:31] <erikg> what correlates to that in the pythonic modules proposal?
[19:32] <kriskowal> i see. you would prefer implicit exportation of all of what would be globals in normal javascript: which would include top level var declarations and assignment to free variables not captured by the scope
[19:32] <kriskowal> yeah, in the pythonic proposal, all top level vars are implicitly exported.
[19:32] <kriskowal> which is true to the name; that's how python works too
[19:32] <erikg> i'm in agreement with the idea that this is a deficiency with js that you can leak top-level variables from a loaded module into the global scope
[19:33] <erikg> right, python works that way
[19:33] <deanlandolt_> that approach strikes to be a breach of python's zen "explicit is better than implicit"
[19:33] <deanlandolt_> s/to be/me as/
[19:33] <kriskowal> in any case, the reason for not doing that is that it's not possible to implement a loader for that behavior in every engine
[19:33] <erikg> deanlandolt_: but it also makes life much easier for programmers...
[19:33] <deanlandolt_> how?
[19:33] <kriskowal> erikg, it also makes life a lot harder sometimes
[19:33] <erikg> you can take any script and require it
[19:34] <erikg> and it works
[19:34] <deanlandolt_> is it really so hard to say var mymodule = exports and go about your business?
[19:34] <deanlandolt_> true, but it's really not that hard to port
[19:34] <erikg> deanlandolt_: interesting
[19:34] <kriskowal> that doesn't solve erikg's problem
[19:34] <kriskowal> if i understand it correctly
[19:34] <deanlandolt_> no, it doesn't...i thought his complaint was largely cosmetic
[19:35] <kriskowal> it amounts to brevity, i think
[19:35] <erikg> my observation from python, and this is purely personal, is that there is a big benefit to keeping the code-level differences between executable scripts and modules very low
[19:35] <erikg> brevity... right
[19:35] <Wes--> erikg: commonjs programs are commonjs modules
[19:35] <kriskowal> well, with commonjs, there is also no difference between executable scripts and modules, but only because they both use "exports" explicitly
[19:36] <kriskowal> and even in python, it's sketchy to use a program as a module; the implied purpose is to capture the end state of the program
[19:36] <kriskowal> without having to involve the program author
[19:37] <kriskowal> which doesn't really happen in practice. programs used as modules usually capture the program end state in a main() function
[19:38] <erikg> i am digesting all of this
[19:39] <kriskowal> the real problem with implicitly exporting all top scope variables is securability and safety
[19:39] <erikg> kriskowal: please continue
[19:39] <kriskowal> now, i'm not one to bundle up every programmer in bubble wrap like java does, but?
[19:39] <deanlandolt_> kriskowal: ha!
[19:40] <kriskowal> in python, it's a common hazard to "from module import *", which implicitly exports as well as imports a indeterminate set of symbols, which can vary with architectural evolution
[19:41] <kriskowal> so, the import * and the implicit export features, when combined, lead to unpredictable bugs when you upgrade packages
[19:41] <kriskowal> e.g., form a import *; from b import *
[19:41] <kriskowal> you're using a module's foo
[19:41] <erikg> kriskowal: importing in this way is actually considered bad practice except for small projects
[19:41] <kriskowal> then you upgrade b, unknowingly introducing a likewise named but different behavior foo
[19:41] <erikg> it's obviously dangerous. but it can be convienient...
[19:41] <kriskowal> i agree
[19:42] <kriskowal> but the counter argument is that?it's actually not that inconvenient *not* to do it.
[19:42] <erikg> note that i'm not at all interested in that kind of module loading
[19:42] <kriskowal> for a great deal of safety added
[19:42] <kriskowal> so that's one argument.
[19:42] <kriskowal> the safety hazard argument
[19:42] <kriskowal> the other argument is securability.
[19:43] <erikg> agreed, it's not inconvenient to NOT do from N import *
[19:43] <kriskowal> object capability programming depends on the ability to hide data in your type or, in this case, module's closure
[19:43] <erikg> although it can be useful for development to reduce keystrokes on the command line as such
[19:43] <kriskowal> in a type constructor, "var foo" is conceptually "private"
[19:43] <erikg> kriskowal: so what python does is uses funny-named words
[19:43] <kriskowal> and "this.foo" is conceptually public
[19:44] <kriskowal> right, which resolves a safety issue, but is also not securable
[19:44] <erikg> s/words/identifiers, such as __private_value_or_method
[19:44] <erikg> yup
[19:44] <deanlandolt_> erikg: true, but you could write a helper that flattened a module into your globals if you want
[19:44] <erikg> deanlandolt_: exactly, i was thinking the same. but its use is convenience at the cost of safety.
[19:45] <kriskowal> so, it's actually quite elegant to mirror the "var foo is private, something.foo" paradigm between type constructors and module scope
[19:45] <deanlandolt_> of course -- i'm just saying it's still possible (e.g. for your command line convenience example)
[19:45] <kriskowal> now, originally i proposed that "something" be "this" to make it perfectly symmetric
[19:46] <kriskowal> but, "this" has a pile of its own issues, which usually lead to you assigning it to a different name, like "var self = this" or "var that = this"
[19:46] <kriskowal> so, we bypassed those issues by assigning it to "exports"
[19:46] <kriskowal> which *also* has the benefit of potentially making the migration to a native "export" keyword easier.
[19:46] <erikg> interesting...
[19:46] <kriskowal> exports.foo = thing
[19:46] <kriskowal> export foo = thing
[19:48] <erikg> in your perspective, what is problematic about: http://wiki.commonjs.org/wiki/Modules/PythonicModules#Programming_Notes ?
[19:51] <kriskowal> ah, it's not. it's boilerplate though.
[19:52] <kriskowal> that is certainly not the crux of the argument though.
[19:53] <kriskowal> just as a matter of elegance though, think about how you'd export things within the enclosure
[19:53] <hannesw> erikg: helma ng implements both securable and pythonic modules
[19:53] <erikg> hannesw: how are they distinguished?
[19:53] <kriskowal> pythonic is strictly an extension of securable
[19:54] <erikg> ok
[19:54] <hannesw> it's an extension really
[19:54] <erikg> i'll read up on it
[19:54] <kriskowal> well, not strictly. you could have pythonic without certain features of securable
[19:54] <hannesw> if you use per-module top-level scopes
[19:54] <hannesw> right
[19:55] <erikg> kriskowal: in response to the earlier 'think about ...' judging by the description you would assign functions and variables to the global scope within the closure
[19:55] <hannesw> so helma ng implements require() on top-level module scopes
[19:55] <kriskowal> right, either with "this.foo" or free assignment like "foo = "
[19:55] <hannesw> which lets us implement an include(), for instance, that loops over the module object and sets properties in the importing scope.
[19:56] <erikg> sounds straightforward
[19:56] <hannesw> but i got bitten by include() already, so I'm not going to use it at least for the core libraries, i think
[19:57] <hannesw> well it's ok for simple things, and for the shell.
[19:57] <tlrobinson> erikg: i just skimmed the conversation so i don't know if it was mentioned, but its impossible to implement modules that implicitly export all "globals" in the browser (at least without complex preprocessing or crazy iframe trickery)
[19:57] <Wes--> hannesw: I also have a scoped-include -- it's handy for quickies but I prefer require() for "real work"
[19:58] <tlrobinson> (that was one of my big objections to pythonic modules)
[19:58] <erikg> tlrobinson: we were talking about include('module') as a function which first loads the module, and then exports its members to the global scope
[19:59] <erikg> Wes--: what project are you working on?
[19:59] <tlrobinson> ah
[19:59] <hannesw> actually, you can have pythonic modules without the include (just a matter of discipline)
[19:59] <erikg> right, include seems to be equivalent to 'from X import *' in python
[19:59] <erikg> which can be a mess
[19:59] <Wes--> erikg: for (export in require("module")) this[export] = require('module')[export]
[19:59] <Wes--> erikg: gpsee
[19:59] <Wes--> erikg: code.google.com/p/gpsee
[20:00] <hannesw> with pythonic modules, include doesn't use the global scope - only the importing scope sees the imported stuff
[20:00] <hannesw> that's the beauty of it
[20:00] <tlrobinson> (except "export" is a reserved word ;) )
[20:00] <erikg> hannesw: ahhh
[20:01] <hannesw> tlrobinson: not in most modern js engines, afaik (i think spider/tracemonkey was the last to free "export")
[20:02] <tlrobinson> hannesw: oh? my version of rhino says its reversed
[20:02] <tlrobinson> reserved, even
[20:02] <Wes--> It's reserved in ES3, freed in ES5 IIRC
[20:02] <hannesw> i think it's "reserved for future use" or something like that
[20:03] <Wes--> hannesw: lots of java reserved words were reserved in ES1 and not unreserved until ES5
[20:03] <hannesw> rhino has a feature switch to allow it
[20:03] <hannesw> i thought it was allowed by defaut, but i'm obviously wrong
[20:04] <tlrobinson> that's probably something we should specify in commonjs
[20:04] <Wes--> tlrobinson: you actually can't unreserve them just by stating that they are
[20:04] <deanlandolt_> but can we? if es3 will choke on it it's not es5 that's backward compatible with es3, right?
[20:05] * Wes-- nods
[20:07] <deanlandolt_> i'm surprised they even bothered unreserving words for es5 -- it's not like anyone will be able to use them safely for years
[20:07] <tlrobinson> i mean if hannesw is right and all modern js engines allow certain previously reserved words then it could be an issue. i do think we should forbid all the ES3 reserved words
[20:09] <hannesw> i think there's no change between es3 and es5 here - both list these words as "reserved for future use" or something
[20:09] <hannesw> i could be wrong though
[20:09] <tlrobinson> oh ok
[20:10] <hannesw> it was just a practical move to allow them because some browsers did, and then those that didn't were perceived as buggy
[20:10] * hannesw is looking up the mozilla bug...
[20:13] <hannesw> here it is, i think: https://bugzilla.mozilla.org/show_bug.cgi?id=249211
[20:14] <hannesw> wrong one, have to look again...
[20:26] <hannesw> ok, here it is now: https://bugzilla.mozilla.org/show_bug.cgi?id=240317
[20:27] <hannesw> https://bugzilla.mozilla.org/show_bug.cgi?id=497869
[20:44] <ryah> does http://code.google.com/p/interoperablejs implement modules 1.1
[20:44] <ryah> ?
[20:45] <ryah> seems like relative paths are not prefixed by "./2
[20:45] <ryah> "./", mean
[21:17] <kriskowal> ryah the iojs tests are meant to be run individually with their own directory as the module search path
[21:17] <kriskowal> the reason for that is that the tests need to be able to test both absolute and relative ids
[21:18] <ryah> ah
[21:18] <kriskowal> the scaffolding for running them varies from implementation to implementation. when we have a loader and sandboxing standard, we'll be able to unify the scaffolding
[21:19] <kriskowal> in narwhal, we use a sandbox scaffold. wes injects the non-spec "print" method and runs them individually, i think.
[21:22] <ryah> okay

 

 

Logs by date :