2009-11-02:

[2:21] <ashb> hmmmm polyglot is cool.
[2:21] <ashb> `polyglot allows you to load Treetop grammars directly in Ruby via require, which makes development a bit easier.'
[12:49] <ondras> so
[12:49] <ondras> v8cgi now supports require.paths
[12:49] <ondras> :)
[13:04] <kpobococ> ondras: what's it for, anyway?
[13:05] <ondras> kpobococ: Config.libraryPath
[13:05] <ondras> this option is now obsolete in favor of require.paths
[13:05] <ondras> additionaly, require.paths is an array so multiple paths can be searched
[13:05] <kpobococ> so, I can configure libraryPath during runtime?
[13:05] <ondras> yes (but you configure require.paths, there is no libraryPath now)
[13:06] <ondras> btw, you were able to do that before as well
[13:06] <kpobococ> shouldn't it have a default value or something? I don't keep all my libs inside app root or nowhere near for that matter
[13:06] <ondras> just by adjusting Config.libraryPath
[13:06] <ondras> well, require.paths is setup in v8cgi.conf
[13:06] <ondras> just as Config.libraryPath was
[13:06] <kpobococ> ah, ok
[13:07] <ondras> just do a svn up and check it yourself :)
[13:07] <kpobococ> I don't have SVN access to v8cgi yet, or I don't know how to set it up :)
[13:07] <kpobococ> I'm a google code noob
[13:09] <ondras> :)
[13:09] <ondras> what os do you use?
[13:09] <kpobococ> Win XP
[13:10] <ondras> ah
[13:10] <ondras> so obtaining the source code is not very interesting for you
[13:10] <kpobococ> I've got NetBeans IDE \w SVN support
[13:10] <kpobococ> actually, it is :)
[13:10] <ondras> you cannot test anything without compiling it
[13:11] <ondras> but as you wish
[13:11] <ondras> http://code.google.com/p/v8cgi/source/checkout
[13:11] <ondras> here is the info regarding checking out the code
[13:11] <kpobococ> thanks
[13:12] <kpobococ> how do you compile apache modules for Win then?
[13:12] <ondras> using a compiler :)
[13:13] <ondras> v8cgi was initially compiled with MSVC, but I recently made a switch to MinGW
[13:21] <ashb> minGW is so much easier to work with
[13:21] <kpobococ> I've got MinGW installed, so unless I'm missing some libs, I'll be able to compile it
[13:22] <ashb> the other advantage of mingw is you can easily ship a 'dev kickstart bunld'e
[13:23] <ashb> so - anyone know of a parsing expression grammar for JS?
[13:24] <ashb> ah http://www.deadpixi.com/Deadpixi.COM/Kouprey.html it seems
[13:26] <ashb> doesn't looke as nice to use as treetop tho
[13:26] <ashb> also its examples suggest using with
[13:27] <ashb> `with (Grammar)` that is
[13:29] <ondras> kpobococ: you will also need scons
[13:29] <ondras> and v8 obviously
[13:29] <ondras> so first try to download v8 and compile it
[13:30] <kpobococ> scons?
[13:30] <ashb> a build system written in python
[13:31] <kpobococ> URL please
[13:32] <jabis> http://code.google.com/p/v8/
[13:32] <ashb> http://google.com/?q=scons
[13:32] <ashb> :P
[13:32] <kpobococ> thanx
[13:33] <jabis> http://www.scons.org/
[13:33] <jabis> for scons :)
[13:45] <ashb> anyone fancy working with me on creating a PEG that is more like treetop (rather than where the grammar files are distinct and not in some kluddgy javasctipt representation)
[14:27] <kpobococ> so, why do you think doing something like `Object.prototype.foo = function() {/*...*/}` is wrong and dangerous?
[14:31] <ashb> Object isn't so bad
[14:31] <ashb> but Array.prototype.x = 1
[14:31] <ashb> a = []; for (var i in a) { print(i) }
[14:31] <ashb> will print 'x'
[14:31] <kpobococ> not if you use hasOwnProperty()
[14:32] <ashb> wyeah but thats a fucking verbose pain in the ass
[14:32] <kpobococ> a = []; for (var i in a) { if (!this.hasOwnProperty(i)) continue; print(i); }
[14:32] <ashb> i shouldn't *have* to
[14:32] <ashb> which is where Object.defineProperty comes in
[14:32] <kpobococ> well, I've learnt that it is best to use for (var i = 0; i < a.length; i++) to iterate through arrays
[14:32] <kpobococ> than to use for (var i in a)
[14:33] <ashb> i usually use for each (k in a)
[14:33] <kpobococ> I'm not familiar with for each, i just define own Array.prototype.each method
[14:33] <ashb> for each (x in a) {} => for each (i in a) { var x = a[i]; }
[14:34] <ashb> i.e. what I *acutally* want when you are iterating over arrays :)
[14:34] <ashb> shame its part of E4X and thus not implemented anywhere but mozilla
[14:34] <frodenius> for..in and for each are both very slow
[14:35] <ashb> they haven't special cased them for (fast) arrays then?
[14:35] <kpobococ> that's why you should define your own each method
[14:35] <ashb> eh - function closures are too verbose most of the time
[14:35] <ashb> i'm picky :D
[14:36] <kpobococ> what?
[14:36] <ashb> a.forEach(function(x) { ... } )
[14:36] <ashb> is what you are advocating?
[14:36] <kpobococ> a = []; a.each(function(item, key)) { print(key); }
[14:36] <kpobococ> a = []; a.each(function(item, key) { print(key); });
[14:37] <ashb> the anon function grates a bit
[14:37] <kpobococ> you don't like anon functions?
[14:37] <ashb> also forEach. 1) libraries provide it, 2) its part of ES5
[14:37] <ashb> not always
[14:37] <frodenius> and calling a function is even slower than using for..in
[14:37] <kpobococ> I usually make it an alias
[14:37] <ondras> Array.prototype.X is okay, Object.prototype.X is very evil :)
[14:37] <kpobococ> it's not that slow for me to be concerned for it to be slow
[14:38] <ondras> Object is evil because it brakes existing code which uses for (var p in obj)
[14:38] <kpobococ> why is it evil, ondras?
[14:38] <ashb> its not the speed, just the visual style
[14:38] <ashb> ondras: unles you use Object.defineProperty :)
[14:38] <kpobococ> what's Object.defineProperty?
[14:38] <ondras> Array is okay because most people are used to iterate through them in normal fashion :)
[14:38] <kpobococ> any doc there?
[14:38] <ashb> kpobococ: it comes from ECMAScript 5 spec
[14:38] <ashb> http://flusspferd.org/docs/js/Object#.defineProperty
[14:39] <kpobococ> most people should get used to iterate through object using hasOwnProperty
[14:39] <ashb> is our implementation of it
[14:39] <kpobococ> I believe
[14:39] <ashb> hasOwnProperty for iterator is a workaround, not the solution
[14:39] <kpobococ> why isn't it a solution?
[14:39] <ondras> ashb: how does this solve the Object.prototype.unwantedStuff issue?
[14:39] <ondras> kpobococ: there are MILLIONS of lines of existing code which iterates through object without hasOwnProperty
[14:40] <ashb> ondras: Object.defProp(Object.proto.unwanted, ...); for (a in {}) { print("I never get here"); }
[14:40] <ashb> ondras: thats how
[14:40] <ashb> for (a in x) only iterates over enumerable properties
[14:40] <ondras> ashb: I am afraid about portability here
[14:40] <ashb> Object.defineProperty lets you create non-enumerable properties from JS space
[14:40] <ashb> ondras: sure, its ES5 only and wont work in a browser
[14:41] <kpobococ> ondras: logically, it is incorrect to not use hasOwnProperty. Because you iterate through object properties and it's prototype properties, where you want to iterate through object own properties only!
[14:41] <ashb> *OR* you could not stuff stuff in Object.prototype or Array.prototype :)
[14:41] <ashb> unless you can make it non enumerable
[14:41] <ondras> ashb: v8 for instance does not support defineProperty
[14:41] <kpobococ> but that is one of the greatest features of javascript - being able to add methods to object prototypes!
[14:41] <ashb> ondras: neither did spidermonkey - you can write it in C and expose it tho
[14:42] <ondras> kpobococ: actually, I don't care which properties I enumerate
[14:42] <ashb> kpobococ: sure. just dont do it on the built ins unless you know the pain it will cause
[14:42] <kpobococ> I would rather say "use hasOwnProperty" than "never extend Object.prototype"
[14:42] <ondras> kpobococ: I just add stuff to a blank object and then iterate
[14:42] <ondras> kpobococ: that kind of makes sense, but it is too late to say so now :)
[14:42] <kpobococ> ashb: well, that's true
[14:42] <ondras> 0.001% of people writing JS are aware that hasOwnProperty even exists
[14:42] <ondras> ...
[14:43] <kpobococ> it's never too late to refactor :)
[14:43] <ashb> ondras: since the C api to V8 must be able to create non-enumerable properties
[14:43] <ondras> ashb: true
[14:43] <ashb> so write a function and bind it to JS, thats what we've done
[14:43] * ashb goes back to proper work
[14:43] <ondras> yes, that could be done
[14:43] <ondras> but the second issue remains:
[14:43] <ondras> conflicts.
[14:44] <ashb> ondras: its what we (commonjs) have agreed upon i think - to support all features of ES5 that can be implemented in ES3 (via C/native APIs)
[14:44] <ondras> doing Object.setSomethingInPrototype influences other code and that is bad.
[14:44] <angelm> hi ondras
[14:44] <ondras> angelm: hi :)
[14:44] <ashb> i.e. JSON.parse should always be avilable etc. etc.
[14:44] <ondras> we are just discussing prototype enhancements :)
[14:44] <angelm> i packed the webkit functions to one file
[14:45] <angelm> ah
[14:45] <kpobococ> ondras: I am not going to extend Object.prototype in v8cgi modules, but I *will* do so in my apps and I *will* expect people to use hasOwnProperty :)
[14:45] <ondras> kpobococ: good luck :))
[14:45] * ondras is not going to use hasOwnProperty in his code :)
[14:45] <ashb> kpobococ: then you will cause bugs, cos lots of people wont :)
[14:45] <kpobococ> and I will be pissed on v8cgi for not working properly with that :)
[14:46] <ondras> but adding the Object.defineProperty sounds like a good idea
[14:46] <kpobococ> ashb: that's too bad for them, I think :)
[14:46] <ondras> kpobococ: if you take the defineProperty route, existing code won't break
[14:46] <ashb> depends if you want people using your code or not ;)
[14:46] <ashb> man those old docs look so ugly compared to pdoc
[14:46] <ondras> you will just enter the world of unpredictable collision code :)
[14:46] <ashb> 'unpredictable collision'?
[14:47] <ondras> ashb: Builtinsomething.prototype.myMethod
[14:47] <ashb> oh you mean of lots of things monkey patching Object#?
[14:47] <ashb> yeah
[14:47] <ondras> angelm: so, are there any things you want to discuss?
[14:47] <ondras> I have to leave in cca 1/2 hour
[14:47] <kpobococ> ondras: I think not taking a route I like because there may be bugs in existing code is wrong. Bugs should be fixed, not worked around
[14:47] <kpobococ> ultimately, at least
[14:47] <ondras> but the good news is that I managed the DOM and pgsql modules to compile on windows :)
[14:48] <ondras> kpobococ: I don't consider "for (var p in x)" a bug...
[14:48] <angelm> the require-think doesn't load the the files always
[14:48] <angelm> ah cool :)
[14:48] <ondras> angelm: okay, show it please
[14:48] <ashb> ondras: what DOM module are you using?
[14:48] <ondras> ashb: some xerces-c based
[14:48] <ondras> I have never used it, it is a contribution
[14:48] <kpobococ> ondras: it's a structure, but developers using it should be aware of what it actually does
[14:48] <ashb> oh so just an XML parser which has DOM(like) api?
[14:48] <angelm> i don't now why it some times works
[14:49] <ondras> ashb: probably... I am ashamed by not knowing the full api for my project :)
[14:49] <ashb> ahaha
[14:49] <ashb> join forces with us >_>
[14:49] <ashb> write a v8 engine for flusspferd
[14:49] <ondras> angelm: please show some example...
[14:49] <ashb> http://juicejs.org/combined-docs/ we have shiny docs (soon)
[14:50] <kpobococ> this sounds just like "Join the dark side. We have cookies!"
[14:50] <ondras> kpobococ: we are; that is why I pointed out that Object.prototype.X is a delicate thing :)
[14:51] <MisterN> kpobococ: you think flusspferd is the dark side?
[14:51] <kpobococ> MisterN: i don't know what it is, and people always fear the unknown
[14:51] <ondras> ashb: pdoc looks cool; too bad it requires ruby :)
[14:51] * ondras is happy with jsdoc
[14:51] <ondras> js should be documented exclusively by js-based doctools :P
[14:52] <kpobococ> ondras: I'm just saying code should be written as compatible as possible
[14:52] <evilstreak> ondras: errr
[14:52] <evilstreak> doesn't jsdoc need perl?
[14:53] <ashb> JSDoc is rhino
[14:53] <angelm> http://webhike.de/labs/v8cgi/webkit/tests/samples.jx
[14:53] <ondras> :)
[14:53] <kpobococ> JSDoc is implemented in Perl, as as such, requires the perl executable
[14:53] <evilstreak> ok, rhino
[14:53] <kpobococ> lol
[14:53] <angelm> the print file can not be loaded
[14:53] <evilstreak> rhino is no better than ruby
[14:53] <evilstreak> :P
[14:53] <angelm> from http://webhike.de/labs/v8cgi/webkit/webkit_col.js
[14:53] <ashb> ondras: i plan on re-writing pdoc to commonJS at some point soon anyway >_>
[14:53] <ashb> kpobococ: old JSDoc is perl, the more modern one is Rhino
[14:53] <MisterN> kpobococ: no need to fear flusspferd. http://flusspferd.org
[14:54] <ondras> angelm: well, you just don't understand what require does
[14:54] <Wes--> I dunno man
[14:54] <ondras> it has no sense to call it without using the returned value
[14:54] <Wes--> I heard hippopotamusses can really hurt you
[14:54] <ondras> var print = require("./print").print
[14:54] <ondras> that is what you want to do
[14:54] <angelm> hm...
[14:54] <kpobococ> "Javascript bindings for C++"
[14:54] <ondras> require *returns* the exports
[14:54] <kpobococ> taht's it, flusspferd is evil
[14:54] <angelm> returned value?
[14:54] <ashb> MisterN: we need to change the title :)
[14:55] <ondras> kpobococ: flusspfer is like v8cgi, but atop other js engine(s)
[14:55] <ondras> *flusspferd
[14:55] <ondras> Wes--: :P
[14:55] <MisterN> kpobococ: v8cgi uses c++ too.
[14:55] <MisterN> as does v8
[14:55] <kpobococ> ashb: and name
[14:55] <kpobococ> MisterN: but it doesn't say it, like, in your face ^__^
[14:56] <angelm> strangelly on the write.js it loades the file, not so on print.js (witch depends on sprintf?)
[14:56] <MisterN> you're an idiot, sorry to say it
[14:56] <kpobococ> "Javascript bindings for C++"
[14:56] <MisterN> but it's true.
[14:56] <kpobococ> that's scary
[14:56] <kpobococ> MisterN: you have absolutely no sense of humor
[14:56] <ondras> angelm: what is the code now?
[14:56] <kpobococ> and yes, I am an idiot
[14:56] <kpobococ> so what?
[14:56] <ashb> its true - germans dont
[14:56] <ondras> no flame guys, we are trying to solve some issues with require .)
[14:56] <angelm> ondras: http://webhike.de/labs/v8cgi/webkit/print.js
[14:56] <ashb> :)
[14:57] <MisterN> ashb: even if i had a sense of humor, what kpobococ said couldn't be considered a good joke
[14:57] <ondras> angelm: so, your "print" module exports one function
[14:57] <ondras> therefore, it should be used as "var print = require('./print').print;"
[14:57] <MisterN> "You use C++ that's evil!!! And you even say it!!! And your name sucks!!!"
[14:57] <MisterN> sorry but i consider that insulting.
[14:57] <ondras> angelm: the same applies to all other modules
[14:58] <MisterN> but then it's good to know what the common soul thinks.
[14:58] <kpobococ> MisterN: I never said your name sucks. But it's fairly complicated
[14:58] <angelm> ah - that information wasn't in the api
[14:58] <ashb> FLAME WAR. FLAME WAR.
[14:58] <ondras> angelm: actually, it is best to read the commonjs modules docs
[14:58] <MisterN> kpobococ: easier than hippopotamus :P
[14:58] <angelm> ;)
[14:59] <kpobococ> MisterN: and I already said people fear what they don't know. I don't know C++, so I consider it evil. And that was the joke.
[14:59] <ondras> angelm: http://wiki.commonjs.org/wiki/Modules/1.1
[14:59] <angelm> the other question is if the print function should be implementaded in strings?
[14:59] <MisterN> kpobococ: well, at least you're honest.
[14:59] <ondras> MisterN: actually, having an "evil" reputation might be tempting for users :)
[15:00] <ondras> angelm: that is another story, not related to require()
[15:00] <ashb> kpobococ: use http://juicejs.org/ instead then
[15:00] <MisterN> ondras: heh good idea
[15:00] <kpobococ> MisterN: not knowing something is nothing to be ashamed of. I just never came across much C++ to learn it
[15:00] <kpobococ> MisterN: and now I'm too lazy, I think
[15:00] <ashb> C++ is quite fruity. I'd much rather write JS
[15:00] <MisterN> kpobococ: being lazy is something to be ashamed of :)
[15:00] <angelm> yes
[15:01] <ondras> ashb: +1
[15:01] <MisterN> i like c++ :)
[15:01] <kpobococ> ashb: that's what I thought
[15:01] <ashb> MisterN: lies. the qualities of a good programmer: Laziness, Impatience and Hubris
[15:01] <kpobococ> as I said. Evil MisterN
[15:01] <ondras> MisterN: 90% of my time getting v8cgi compiled on windows, I am fighting with different exported symbol decorations on gcc/msvc :/
[15:02] <kpobococ> and here it goes
[15:02] <MisterN> ondras: but that's due to the windows compiler not c++ :)
[15:02] * kpobococ went smoking. Not that anyone cares (c) The Big Bang Theory
[15:02] <ashb> s/compiler/DLL model/
[15:02] <angelm> hm i have require ('./print').print;
[15:02] <angelm> and still ReferenceError: print is not defined at occures
[15:02] <ashb> ondras: do you do The Right thing with './foo'?
[15:03] <MisterN> ashb: a good programmer must avoid unnecessary effort, yeah, because that's quite the point of automation
[15:03] <ondras> ashb: yes :)
[15:03] <ashb> ondras++
[15:03] <ondras> ashb: relative includes do not use global search roots :)
[15:03] <ashb> good chap
[15:03] <ondras> MisterN: yes yes .. but if the world was written in js, these issues would vanish :)
[15:04] <ondras> angelm: okay, so what is the code now?
[15:04] <ondras> the code which throws an exception
[15:04] <MisterN> ondras: the world being written in js is just not an option :)
[15:05] <MisterN> so most people say to themselves "i need another language, so let's use C"
[15:05] <MisterN> which is, in my eyes, a stupid choice.
[15:05] <angelm> ondras: the print: http://webhike.de/labs/v8cgi/webkit/print.js
[15:05] <angelm> and the http://webhike.de/labs/v8cgi/webkit/webkit_col.js
[15:05] <ashb> and which line throws the error?
[15:06] <ashb> angelm: require ('./print').print does nothing
[15:06] <ashb> it certainly doesn't assing print as a top level variable
[15:06] <angelm> hm?
[15:06] <ashb> function x() {};
[15:06] <ashb> x;
[15:06] <ashb> is what you've done
[15:06] <angelm> have i to use print = require('./print').print ?
[15:06] <ondras> angelm: you have to assign results of require() to something!
[15:06] <ondras> require just returns exports
[15:06] <ondras> easy peasy
[15:06] <ondras> :)
[15:07] <angelm> than include is simplier and easy :)
[15:07] <ondras> yes, but it pollutes the global object :)
[15:08] <ondras> and include() is not part of a commonjs standard
[15:08] <evilstreak> does anyone have a canvas implementation yet?
[15:08] <Wes--> firefox and safari? :)
[15:09] <ondras> v8cgi has only gd
[15:09] <ondras> afk, going home from work
[15:09] <angelm> ok, require handles only one object, that can be returned?
[15:09] <evilstreak> Wes--: :P
[15:09] <MisterN> evilstreak: i think ruediger started writing one for flusspferd, but that was more a proof-of-concept
[15:09] <ashb> yeah, using SDL wasn't it
[15:10] <ondras> angelm: require returns exports from a module
[15:10] <angelm> anyhow it sometimes (on some files) works like include
[15:10] <ondras> no, it never pollutes the global scope unless you do something dirty in your module
[15:11] <angelm> because the String.prototype.print function exports.print can not be load
[15:12] <kpobococ> angelm: you can use require like that: var ex = require('./somelib.js'); var print = ex.print; var foo = ex.foo; delete ex;
[15:13] <ondras> delete ex is incorrect; var'ed variables cannot be deleted :)
[15:13] <ondras> dtach
[15:13] <kpobococ> ondras: really? what about delete this.ex?
[15:13] <kpobococ> or delete global.ex
[15:14] <kpobococ> anyway, I have a noob js question: suppose I do this: var Stack = function() {/*...*/} Stack.prototype = new Array;
[15:14] <angelm> aha if there is more as one function in the required file, unless if only one function is exportet, the file can not be loaded
[15:14] <kpobococ> how can I call Array initialization from Stack?
[15:15] <Wes--> kpobococ: ES3 does not specify that the global variable is also the var object
[15:15] <kpobococ> Wes--: delete this.ex then?
[15:15] <kpobococ> I mean, var assigns values somewhere, right?
[15:16] <Wes--> kpobococ: sure, it has to assign them somewhere, but there is no ES3 mechanism to manipulate the symbol table other than the "var", and "function" keywords IIUC
[15:16] <Wes--> s/symbol table/var object/
[15:16] <ashb> just happens that all implementations (except mayve v8?) use the global as the root var object
[15:17] <Wes--> ashb: spidermonkey does not IIUC (at least with JSOPTION_VAROBJ_FIX)
[15:17] <ashb> oh yeah
[15:18] <kpobococ> how can I unassign a variable assigned with var then?
[15:18] <ashb> i really wish the spec said that the varobj must be a normal Object (sans any prototype) cos then you can do all sorts of fun
[15:22] <angelm> ondras: i will describe the require problem in the discussion forum
[15:23] <kpobococ> how can I unassign a variable assigned with var then?
[15:23] <ashb> kpobococ: you can't reliably
[15:23] <ashb> delete this.a might work
[15:23] <ashb> or you can do a = undefined
[15:23] <ashb> but the var is still present
[15:23] <ashb> kpobococ: why do you want to?
[15:24] <kpobococ> ashb: to not have unneccessary vars in the scope.
[15:24] <ashb> premeture optimization?
[15:24] <ashb> i.e. why do you think its needed?
[15:25] <kpobococ> ashb: so garbage collector can free memory
[15:26] <ashb> 1) dont create them in the first place, 2) design it such that they are in a function and go out of scope that way
[15:26] <ashb> 3) a= undefined
[15:26] <ashb> thems your options
[15:26] <kpobococ> so, using a closure, like (function() {})(); is the solution, then
[15:27] <ashb> probably yeah
[15:27] <kpobococ> ok
[15:28] <angelm> i take a jet
[15:35] <ondras> re
[15:35] <ondras> hmm
[15:35] <ondras> too late
[15:35] <ondras> :/
[15:35] <ondras> kpobococ: delete global.ex should not work, if global.ex was created with "var ex = .."
[15:36] <ashb> ondras: doesn't in a spidermonkey shell
[15:37] <ondras> the same for v8
[15:37] <ondras> and it is correct
[15:37] <ondras> btw, what is your opinion re. require.call(exports) ? (simplified example)
[15:37] <ashb> oh 'not' missed that
[15:37] <ashb> ondras: not aware what that is
[15:38] <ondras> executing modules with this == exports
[15:38] <Wes--> kpobococ: Your GC argument falls apart with "a = null", note to ashb, "a = undefined" may not work everywhere
[15:38] <ashb> oh, erk! dont like it like that
[15:38] <ashb> Wes--: really?
[15:38] <ondras> ashb: in what scope are modules executed in fp?
[15:38] <Wes--> I'm not sure undefined is a keyword, would have to check the spec
[15:38] <ashb> ondras: each module has its own scope
[15:38] <MisterN> Wes--: huh? what else would it be?
[15:38] <ashb> (bascially each module is wrapped in function(require,module,exports) {})
[15:39] <ondras> ashb: any advantage? does it make sense to use "this" in pf's module?
[15:39] <Wes--> I think it's a variable whose value is undefined..... at least it was a million years ago. ES3 might have changed that
[15:39] <ashb> MisterN: its a value that can be redefine
[15:39] <ashb> undefined = "a"
[15:39] <Wes--> used to be, "var undefined = void 0;"
[15:39] <ashb> for lulz
[15:39] <Wes--> so, yeah
[15:39] <ondras> ashb: also, if that anonymous function gets executed, this==global imho
[15:39] <Wes--> I think null is a better solution, it's always JSVAL_NULL
[15:39] <ashb> ondras: its called with fn.call(fn, require, ...)
[15:40] <ashb> so the thisp is the function itself
[15:40] <ondras> ah
[15:40] <MisterN> Wes--: but void is a keyword?
[15:40] <ondras> okay then
[15:40] <Wes--> MisterN: yes
[15:40] <ashb> it could be called with this = global, but i randoly chose not ot
[15:40] <MisterN> Wes--: this explains the (void 0) stuff that toSource() sometime spits out!
[15:40] <ondras> ashb: v8cgi does it in global right now, but I want to change that
[15:40] <ashb> ondras: the main reason for the function clousre around each module is to not polute global scopes
[15:40] <Wes--> MisterN: Indeed, it does. :)
[15:40] <ondras> ashb: and 'exports' sounds like a good candidate
[15:40] <ashb> ondras: cos smpidermonkey has const x variables
[15:40] <ondras> ashb: yes, the same here
[15:41] <ashb> and without the fn you cant have the same named const in to modules
[15:41] <ondras> hmm
[15:41] <ondras> Wes--: an in gpsee, in what scope are modules executed?
[15:41] <ashb> we've even got a test for that case
[15:41] <ondras> *and
[15:41] <ashb> i think each module gets a whole new global object etc in gpsee
[15:42] <Wes--> ondras: module private scope
[15:42] <ashb> (which is sort of what flusspferd used to do, but that broke tracing and instanceof across module boundaries
[15:42] <Wes--> which is a child of global
[15:42] <Wes--> effectively the same as a closure
[15:42] <ashb> http://github.com/ruediger/flusspferd/blob/master/test/js/lib/modules-test/a1.js
[15:42] <ashb> http://github.com/ruediger/flusspferd/blob/master/test/js/lib/modules-test/a2.js
[15:42] <ashb> http://github.com/ruediger/flusspferd/blob/master/test/js/modules.t.js
[15:42] <ashb> particularly lines 9-13
[15:43] <ondras> Wes--: the question is: "this.xx = 3; if (xx == 3) { ... }" inside a module
[15:43] <ashb> ondras: no way to make that work in spidermonkey without breaking everything else
[15:44] <ondras> (function(){ this.xx = 3; alert(3); })()
[15:44] <ondras> ?
[15:44] <ondras> eh
[15:44] <ondras> .)
[15:44] <Wes--> What does this even mean in that case?
[15:44] <ondras> (function(){ this.xx = 3; alert(xx); })()
[15:44] <Wes--> I thought 'this' was supposed to refer to an instance of a class
[15:44] <ashb> thisd is the owner of the function
[15:45] <ondras> this is the stuff before dot :)
[15:45] <ondras> and if there is no dot
[15:45] <ashb> huh. actually there might be, so long as you dont mind it breaking down the line
[15:45] <ondras> this == (iirc) global
[15:45] <Wes--> What's wrong with using "var" ?
[15:45] <ashb> walk the scope, get the var obj, call the function with this set to the var job
[15:45] <ondras> nothing
[15:45] <kpobococ> how can I tell that an object is instance of a class but NOT one of it's subclasses? Is it possible?
[15:45] <ondras> kpobococ: instance.constructor == ClassName
[15:46] <ondras> err
[15:46] <ondras> this is true also for descendants
[15:46] <ondras> instance.__proto__ == ClassName.prototype
[15:46] <ondras> :)
[15:46] <kpobococ> is __proto__ keyword part of spec?
[15:46] <ondras> no
[15:46] <ashb> there's an ES5 object. isPrototypeOf
[15:46] <Wes--> kpobococ: Try thinking more javascriptily instead. Who care about the name of the class? Properties are more interesting.
[15:47] <kpobococ> Wes--: i just like being able to tell
[15:47] <ondras> Wes--: what am I trying to detect - how is the "this" keyword treated in modules and which way should v8cgi take
[15:47] <ondras> Wes--: because right now this==global and that is not good
[15:47] <Wes--> ondras: My opinion is that "this" shouldn't be used in the module-global scope at all
[15:48] <ashb> so explicitly make it something useless
[15:48] <Wes--> ondras: I would make it null if I had a choice. ;)
[15:48] <ashb> Wes--: you could do
[15:48] <ondras> hehe
[15:48] <ashb> fn.call ;)
[15:48] * ondras agrees that this shouldn't be used in module scope
[15:48] <ondras> ashb: var f=function(){alert(this)}; f.call(null);
[15:49] <ashb> yup
[15:49] <ondras> => [object Window]
[15:49] <ondras> :P
[15:49] <ashb> oh
[15:49] <ondras> no luck here
[15:49] <ondras> I will make it equal to exports :}
[15:49] <ashb> ah so null gets set to the global it seems
[15:49] <ashb> aything else behaves
[15:49] <frodenius> the .call(null) global object leak is fixed in es5
[15:49] <ashb> f.call(1); works for instance
[15:52] <ondras> okay, done with c++ for today
[15:52] <ondras> gonna play some game, more coding tomorrow :)
[16:22] <kpobococ> ok, here's another question I still have no answer to:
[16:23] <kpobococ> var SomeClass = function(/*...*/);
[16:23] <kpobococ> SomeClass.prototype = new Array;
[16:23] <kpobococ> now, how do I call Array constructor from SomeClass?
[16:23] <ashb> Array.call(this)
[16:23] <ashb> but dont count on it working right for native classes
[16:23] <kpobococ> ashb: why?
[16:23] <ondras> especially on array
[16:24] <ondras> inheriting from Array was always problematic
[16:24] <ondras> reasons unknown :)
[16:24] <ashb> kpobococ: cos native classes dont have like normal classes :)
[16:24] <kpobococ> ah, ok
[16:24] <ashb> mainly cos the native classes can tell wether they are called as a function or as as ctor
[16:24] <ashb> c.f Date() vs new Date()
[16:24] <kpobococ> so I should just do for (var i; i < arguments.length; i++) this.push(arguments[i]);
[16:24] <ondras> ashb: your own class can tell as well
[16:25] <kpobococ> ondras: how?
[16:25] <ashb> ondras: value of this?
[16:25] <ondras> ashb: yes
[16:37] <kpobococ> does commonjs spec add support for getters and setters?
[16:40] <the_undefined> does the 1.1 Module system allow loading from urls or absolute paths?
[16:40] <the_undefined> if yes, what would be the proper module id parameter?
[16:42] <ashb> kpobococ: no, thats the job of ECMAScript
[16:42] <ashb> http://annevankesteren.nl/2009/01/gettters-setters
[16:43] <ashb> the_undefined: it doesn't allow it, it doesn't disallow it
[16:43] <kriskowal> kpobococ ES5 defines getters and setters. There has been discussion to the effect of requiring CommonJS compliant implementations to be as ES5 as possible to emulate with ES3
[16:43] <ashb> the_undefined: in flusspferd for instance absolute urls must be prefixed with 'file://'
[16:43] <the_undefined> What about prefixing with a simple '/' ?
[16:44] <evilstreak> not portable to Windows?
[16:44] <kriskowal> it's very likely that we will eventually write a spec for an optional extension that grabs by URL
[16:44] <ashb> kriskowal: i'd rather a spec for generically hooking require behaviour
[16:44] <ashb> so that we can have something like polyglot
[16:45] <kriskowal> yeah, that too probably
[16:45] <ashb> since <3
[16:45] <kriskowal> i need to write a new draft of the loader spec
[16:45] <the_undefined> kriskowal: any ideas on what the syntax could look like?
[16:45] <kriskowal> it's been the intent since january to have a standard API for module loaders
[16:45] <kriskowal> for URL's?
[16:45] <the_undefined> kriskowal: we migrated to CommonJS modules in node.js recently and are a bit at loss about handling urls and absolute paths which we supported before
[16:46] <the_undefined> kriskowal: yeah
[16:46] <the_undefined> kriskowal: would it just be: require('http://.../file.js') ?
[16:46] <ashb> so the way the require spec is written, that is allowed
[16:46] <kriskowal> these are beyond spec, but in Narwhal, /^\// indicates that the id is a fully qualified local file system path
[16:46] <ashb> since require() only specifies what it must do, not what it must not
[16:46] <the_undefined> ashb: not true, it says a module id must not have a '.js' extension
[16:46] <the_undefined> which is problematic for url support
[16:46] <kriskowal> and it believe that eventually the spec would say that the presence of // anywhere in the id implies that it is an URL
[16:47] <ashb> hmmm true.
[16:47] <kpobococ> require must not make coffee
[16:47] <ashb> kriskowal: thats a little bit simplistict
[16:47] <the_undefined> kriskowal: sounds reasonable
[16:47] <ashb> dir = 'bar/'; require(dir + '/foo')
[16:47] <kriskowal> right, that would be bad
[16:48] <kriskowal> require(fs.join('bar/', '/foo')) would have no problems
[16:48] <ashb> true, but mistreating 'bar//foo' as a url is also a problem
[16:48] <ashb> /^[a-z-]+:/ perhaps
[16:48] <ashb> /^[a-z-]+:/ perhaps
[16:48] <kriskowal> c:/
[16:49] <ashb> /^[a-z-]{2,}:/ then :D
[16:49] <ashb> but anyway - that is a detail, we all agree on the intent
[16:49] <kriskowal> /^[^/]+:\/\//
[16:49] <ashb> not all URL schemes have '//'
[16:50] <kriskowal> are any of the url schemes that don't have // ones that we would care about?
[16:50] <ashb> who knows - application defined ones perhaps
[16:50] <the_undefined> I would say only http matters
[16:50] <ashb> might be better to register specific prefixes
[16:50] <ashb> the_undefined: 'dbi:table/1'
[16:50] <kriskowal> yeah, it might
[16:50] <ashb> load from a DB
[16:50] <ashb> springs to ming
[16:51] <ashb> *d
[16:51] <kriskowal> anyhow, we're not in a hurry to spec that out
[16:51] <the_undefined> ashb: well, that should be a custom extension - not in the spec
[16:51] <ashb> require.protocol['http://'] = function() { ... }
[16:51] <ashb> etc
[16:51] <the_undefined> ashb: because with databases you now need authentication
[16:51] <the_undefined> ashb: and possibly even more configuration
[16:51] <ashb> the_undefined: sure - if we've specified how to do it
[16:52] <ashb> absolutelty
[16:52] <kriskowal> at this stage it's sufficient to say that commonjs identifiers are deliberately a strict subset of paths and urls
[16:52] <the_undefined> btw kriskowal, looking forward to see you at jsconf
[16:52] <ashb> tho the no .js extension is a bit odd
[16:52] <kriskowal> i'm looking forward to meeting folks there. how shall i know you?
[16:53] <ashb> oh yeah - someone please talk about Juice if you mention jack/commonjs/jsgi at jsconf. ta :)
[16:53] <ashb> in flusspferd if you do require('x.js') it will look for 'x.js.js'
[16:53] <the_undefined> kriskowal: I'll be hanging out with Ryan Dahl who talks about Node.js. I'm a tall german ; )
[16:53] <the_undefined> kriskowal: I'm sure the server side js crowd will find to one another
[16:53] <kriskowal> right, will definitely see you there
[16:53] * ashb wish i'd found out about it earlier
[16:54] <the_undefined> I got my tickets in the last-minute run
[16:54] <the_undefined> :)
[16:54] <ashb> already had plans by that point sadly
[16:55] <ondras> the_undefined: v8cgi supports absolute require paths
[16:55] <ondras> the_undefined: starting with "/" od "x:/"
[16:55] <ondras> :)
[16:55] <the_undefined> cool
[16:55] <ashb> i guess i should make flusspferd do that too
[16:55] <kriskowal> narwhal tolerates the extension. in its last stage it looks for the exact file name so it can find shell scripts (with no extension) and those that already have an extension specified. tom did something mind-bending to make it all work out
[16:56] <ashb> kriskowal: so r('x.js') will load x.js?
[16:56] <kriskowal> yeah, if all else fails
[16:56] <ashb> that seems very counter to the spec
[16:56] <kriskowal> it will find x.js.js first if there happens to be one
[16:56] <kriskowal> there are two ways to read the spec
[16:57] <ashb> the right way and the wrong way? ;)
[16:57] <kriskowal> one is as a module writer and another as a module loader writer
[16:57] <kriskowal> from the module loader's perspective, it says what must be supported
[16:57] <kriskowal> from the module writer's perspective, it says what you are guaranteed to work everywhere
[16:58] <kriskowal> from the standard library writer's perspective, it says what syntax you must use
[16:58] <ashb> true, but i just worry that peole will take what narwhal does as gospel since it sadly (to me obv.) has the advtange of being first
[16:58] <kriskowal> which is to say, it doesn't prevent extensions
[16:58] <kriskowal> yeah, i understand. that's why we took out "include"
[16:59] <kriskowal> in any case, you will not find a single instance of a fully qualified file name, or an extension, being used in a literal module identifier
[16:59] <ashb> FQ i dont mind
[17:00] <ashb> i also dont have a specific complaint
[17:00] <ashb> i just enjoy a good bitch fest
[17:01] <kriskowal> i certainly don't mind hashing out details
[17:01] <ashb> speaking of which - we still need to continue the talk about binary dont we
[17:01] <kriskowal> yeah
[17:01] <ashb> TZ's are a pain
[17:01] <kriskowal> i don't think this week would be good for war
[17:02] <kriskowal> i've gotta prepare for the con
[17:02] <ashb> speaking?
[17:03] <kriskowal> yeah, i was going to talk about narwhal with tom, and dangoor won't be able to make it, so tom and i are working on his talk too
[17:03] <ashb> ah
[17:03] <ashb> which is CommonJS in general, or bespin?
[17:03] <kriskowal> i should say, it's very likely he won't make it
[17:03] <kriskowal> commonjs in general
[17:03] <ashb> cool - mention them all then :)
[17:04] <kriskowal> with more emphasis on "why" than "what"
[17:04] <ashb> yeah
[17:04] <kriskowal> anyhow, time to head to the office. ttyl
[18:20] <ashb> so whats the portable char limiton module names?
[18:21] <ashb> [a-z_]+ [a-z0-9_]* ( '-' [a-z0-9_]+) *
[18:26] <ashb> (PEG ftw)
[18:31] <Wes--> ashb: that first plus is guaranteed optional
[18:31] <ashb> good point
[18:32] <Wes--> Other than that, seems okay to me
[18:32] <Wes--> although, does the JS RE engine use +? (I honestly don't know)
[18:32] <Wes--> Hmm
[18:33] <ashb> that isn't in regexp syntax, but PEG which is similar by slightly different :D
[18:33] <Wes--> I don't like the final subexpression either
[18:33] <Wes--> ashb: [a-z_][a-z0-9_]*( '-'[a-z0-9][a-z0-9_]*)*
[18:34] <ashb> you dont want to allow something like require('libxml-2') ?
[18:34] <Wes--> I don't think we need to allow module names like hello-_
[18:34] <ashb> oh you dont want foo-_
[18:34] <Wes--> yeah, "fs-base-0" should still be legal
[18:41] <isaacs> hey, i have a question which might seem a bit odd, regarding module naming syntax.
[18:41] <isaacs> all the commonjs implementations map the module name to a file at some point, right?
[18:41] <isaacs> what was the reasoning for not just using a filename or (relative) path?
[18:43] <ashb> dunno - the require() thing was decided before i got invovled
[18:44] <ashb> (i.e. Jan this year)
[18:44] <isaacs> yeah, it was before i got into it, too
[18:44] <isaacs> having worked with nodejs for a while when it just took a filename or url to register a module, it really struck me how much more sensible it was.
[18:44] <_ry> as far as i can search this filename extension issue was only ever brought up by me :)
[18:44] <isaacs> but now nodejs is trying to conform with commonjs (which is generally good, of course)
[18:45] <isaacs> hi, kris
[18:45] <kriskowal> hello mr schleuter
[18:46] <isaacs> kriskowal: http://pastie.org/680364
[18:46] <isaacs> you've been in this commonjs stuff for a while now, you have any thoughts on this?
[18:47] <kriskowal> ah, yeah.
[18:47] <kriskowal> i remember that discussion
[18:47] <kriskowal> my original proposal called for file names
[18:48] <isaacs> you recall the bullet points of the argument for dropping .js and forcing it to camelCase?
[18:48] <kriskowal> robert cerny argued that standard library modules should be agnostic of the backend storage of the modules, e.g., databases
[18:48] <isaacs> right.
[18:49] <isaacs> but it's trivial to use "blah.js" as your key in a db, isn't it?
[18:49] <isaacs> i mean, if you accept strings, then any string should be fine.
[18:49] <kriskowal> and there was argument that .js files would not necessarily back a module, e.g., .dylib, .so, .dll
[18:49] <kriskowal> which is actually the case in many engines
[18:49] <isaacs> hm. i see.
[18:50] <isaacs> so the .dylib, when loaded, would have to register itself as "foo.js" rather than just "foo"
[18:50] <isaacs> and that's less ideal.
[18:50] <isaacs> but i can't help thinking we're optimizing the 20% case and making the 80% case more complicated as a result, and that's backwards.
[18:52] <kriskowal> it's not terribly difficult to append .js
[18:53] <kriskowal> nor to tolerate it if it's provided
[18:53] <isaacs> kriskowal: no, but it does get more complicated when we start using camelCase instead of hyphens or underscores.
[18:53] <kriskowal> camelCase is a separate matter
[18:53] <kriskowal> we definitely have to change camelCase because of the case-insensitive file system issue
[18:53] <isaacs> imo, case sensitivity is a major snag if something is *ever* going to be backed by a filesystem, because many filesystems simply don't tolerate it.
[18:53] <isaacs> gmta, heh
[18:54] <isaacs> also, if we call them paths, we can do things like require("file:///usr/lib/js/module.js")
[18:54] <isaacs> or require("http://foo.com/foo.js")
[18:54] <kriskowal> i'm pushing for lower-case, and the fs-base proposal establishes that as a precedent
[18:54] <kriskowal> i would contend that the spec does not preclude that extension
[18:55] <isaacs> i'm quite partial to lower-css-case for all potentially-filesystem-backed things
[18:55] <kriskowal> it just precludes the use of url's for interoperable modules
[18:55] <isaacs> easy to read, even when it's a hyperlink.
[18:55] <_ry> it does - filename extensions are explicitly disallowed
[18:55] <kriskowal> that should probably be clarified
[18:56] <isaacs> kriskowal: imo, since we allow relative paths, it would make more sense to say that require() takes a URI of some sort, which can vary depending on the implementation.
[18:56] <isaacs> either relative to the current module, or with a protocol (file, http, ftp, etc.)
[18:56] <kriskowal> there's a hitch
[18:56] <kriskowal> a couple caveats
[18:56] <isaacs> k, lay it on me
[18:57] <kriskowal> our id's as defined are not exactly a strict subset of uri's; they default to being relative to require.paths
[18:57] <isaacs> (also, sorry if i'm beating a long-dead horse, thanks for obliging)
[18:57] <isaacs> sure.
[18:58] <kriskowal> lost my train of thought
[18:58] * kriskowal reads back
[18:58] <isaacs> so if you have 7 require.paths, it looks in all of them, like calling a command on the shell will search in $PATH or a php includes or java jar lookups, etc.
[18:59] <kriskowal> that's not necessarily the case. require.paths is not mandated by the spec; it's just mandated that if you do that particular kind of search, you must provide and respect the require.paths values
[18:59] <isaacs> require("http://blah.com/blah.js") would have to be smart enough to not try to search for /usr/lib/js/http://blah.com/blah.js
[18:59] <kriskowal> yes, it would.
[18:59] <kriskowal> and as ashb and i were discussing a couple hours ago, there are a variety of ideas about how to do that
[18:59] <isaacs> and, setting http://blah.com/lib/ as one of your require.paths would be terrible, as it would require an http lookup for every unqualified require()
[19:00] <kriskowal> naturally.
[19:00] <kriskowal> so, then there comes the issue of remote packages
[19:00] <isaacs> bingo
[19:00] <kriskowal> for which ihab, cadorn, and i are proposing an alternate approach
[19:01] <kriskowal> which is to say, an extension that would work on different principles.
[19:01] <isaacs> right, so it would replace require() with something that doesn't have these problems?
[19:01] <kriskowal> extend
[19:01] <isaacs> why don't we just fix the problems with require()?
[19:01] <kriskowal> preferably extend
[19:01] <isaacs> ok
[19:01] <kriskowal> we still need a base line for the standard library.
[19:02] <kriskowal> for commonjs modules, at the very least. modules like fs, fs-base, assert, test, binary, &c
[19:02] <kriskowal> which should just be top-level, so people can count on them being available in any compliant commonjs implementation
[19:02] <isaacs> imo, the number of modules there should be *small*
[19:03] <kriskowal> that is also ihab's pov.
[19:03] <isaacs> i mean, effectively those are globals that every implementation has to agree on. every new one adds significant overhead.
[19:03] <isaacs> in fact, if we could get away with not having any at all, that might be ideal.
[19:03] <kriskowal> i'm taking a more pragmatic approach; there are two schools of thought, both with trade offs. let's just see how it goes.
[19:03] <isaacs> (not exactly globals, since they're only load-on-demand, but still)
[19:04] <kriskowal> in any case, the remote package proposal extends require with a second argument for importing modules from remote packages
[19:04] <kriskowal> require(id, url)
[19:04] <kriskowal> oh, no?
[19:04] <kriskowal> it's require(id, pkgId)
[19:04] <isaacs> and pkgId might be a url to a javascript file or something?
[19:04] <kriskowal> and the pkgId->url mapping occurs in package.json, and can include other package descriptor meta-data, like a hash
[19:04] <isaacs> holy hell.
[19:05] <isaacs> ok.
[19:05] <kriskowal> for security
[19:05] <isaacs> security by complexity?
[19:05] <_ry> isaacs: (the package proposal is actually pretty cool)
[19:05] <kriskowal> so, for this technique, there is no search path
[19:05] <kriskowal> you grab a zip, cache it, and grab modules. your package has a singleton of the module instances from that package
[19:05] <isaacs> _ry: not complaining about the concept. but i'm just trying to find a way that we can maybe do things explicitly
[19:06] <kriskowal> it also scopes the package to package
[19:06] <isaacs> right, so my require("foo", "isaacs-awesome-package") isn't the same as require("foo", "kriskowals-awesome-package")
[19:06] <kriskowal> isaacs: i do not think it would be unreasonable for require(id, pkg) to accept an url, short name, and a package descriptor if need be
[19:07] <kriskowal> right
[19:07] <isaacs> personally, i'd much prefer if the pkgId was a url or file.
[19:07] <kriskowal> i think that makes a fine base-case, but then there's the issue of authenticity
[19:08] <isaacs> and at that point, why not just let us require() that directly? there's convenience in being able to load modules in bunches via a package, but that should probably not happen at run-time.
[19:08] <kriskowal> package.json ~ {"catalog": {"isaacs-awesome-package": {"url": "http://...", "signature": "..."}}}
[19:09] <kriskowal> require(id, "issaccs-awesome-package") 
[19:09] <kriskowal> i think it would be a fine idea to also support require(id, {"url": "http://", "signature": ""}) and require(id, url) as shorthands thereof
[19:11] <kriskowal> the package proposal is not anywhere near final, i don't think. it's got a good basic shape though
[19:11] * isaacs thinking.
[19:11] <isaacs> i worry that that's trending towards more complexity than is necessary.
[19:11] <isaacs> or rather, putting the complexity in the wrong place.
[19:11] <kriskowal> i think that one of the likely matters of contention is what happens to the single-arg form. does it get restricted to the package? does it fall back to the basic behavior? does it do both?
[19:12] <isaacs> bingo.
[19:12] <kriskowal> i think that's resolvable
[19:12] <isaacs> so, i'm also not convinced that loading a package at run-time is ever a good idea.
[19:12] <isaacs> fetching a url is super handy in a few use cases.
[19:13] <isaacs> but downloading a tarball and unpacking it and then finding the module in there? that's a bit snaggly.
[19:13] <kriskowal> in the caja case, the packages would be fetched at compile time
[19:13] <isaacs> right.
[19:13] <isaacs> and they could be cached by narwhal and node and the like.
[19:13] <kriskowal> yeah. cadorn's working on a branch for that
[19:14] <isaacs> what if we did something like this? loadPackage("foo", "http://path/to/foo.tgz"); require("foo/bar.js")
[19:14] <kriskowal> i think it's messy from a sysadmin pov though; we still need to iron out where the packages get stored, how they persists, etc
[19:14] <isaacs> (replace the url with a descriptor, or make it optional if it's a key to a store of package data or something)
[19:14] <kriskowal> believe it or not, that's actually more complicated since it conflates namespaces
[19:15] <isaacs> well, it adds a namespace issue, yes.
[19:15] <isaacs> so tusk or npm or whatever provides your loadPackage() thing would have to know what things are what.
[19:15] <kriskowal> then there's the matter of scope, and malice
[19:15] <isaacs> but how is that any different than apt-get or rpm's namespace issues?
[19:15] <kriskowal> it certainly doesn't solve them. ihab's spec does though.
[19:16] <isaacs> again, it's a matter of where we put the complexity.
[19:16] <kriskowal> i'm suggesting: leave to apt-get, rpm, tusk and what-not the require.paths style of modules, with a sysadmin installing packages behind the scenes, and come up with something new that actually solves the problem
[19:17] <isaacs> hey, do you have a link to ihab's proposal handy? i'd like to read it before i keep complaining about it.
[19:18] <isaacs> (i know it's prolly in the email list, but i have fallen a bit behind on that)
[19:18] <kriskowal> yeah, it's on the wiki?
[19:18] <isaacs> this thing? http://wiki.commonjs.org/wiki/Packages
[19:19] <kriskowal> http://wiki.commonjs.org/wiki/Packages
[19:19] <kriskowal> yeah
[19:19] <isaacs> great, thanks
[19:19] <kriskowal> take some time to digest.
[19:19] <kriskowal> it's very different
[19:19] <isaacs> yeah
[19:20] <isaacs> i'm chuckling a bit at some of the same issues i've been running up against in sketching out npm.
[19:20] <isaacs> a lot of similarity, actually, with some naming differences.
[19:21] <kriskowal> yeah, the names will be bike-shedded when there's more interest
[19:21] <isaacs> sure.
[19:22] <isaacs> also, whereas i'd approached the problem by mapping js files into a place where they could be require()'ed, it seems like he's suggesting that each package sets up a registry of packages it's interested in
[19:22] <kriskowal> i've already made the point several times that the property names should be nouns. s/locate/location/ s/location/url/ s/verify/signature/
[19:22] <isaacs> yes, i agree.
[19:22] <isaacs> properties are nouns, methods are verbs.
[19:23] <kriskowal> yes, exactly.
[19:23] <kriskowal> in fact, there are certain parallels and sharable schema with the apt-get approach
[19:23] <kriskowal> for example, tusk uses a catalog.json that is a registry of?you guessed it?url's of package.json and package.zip with their metadata imported for easy searching
[19:24] <isaacs> my instinct is still that this can get a lot simpler, and that in general, that would be more secure and debuggable.
[19:24] <kriskowal> a strict subset of the catalog json schema could be grafted into package.json for the remote package system
[19:24] <isaacs> tusk is a good example.
[19:24] <kriskowal> i'm not one to argue against making things simpler.
[19:25] <isaacs> hehe :)
[19:25] <isaacs> the simpler solution is usually a lot harder.
[19:25] <isaacs> harder to come up with, anyhow. much easier to use, generally.
[19:25] <kriskowal> ihab and i had a very long discussion back in january that essentially distilled the require/exports proposal out of a much more complicated one
[19:25] <kriskowal> a convergence, really
[19:26] <kriskowal> swept the complexity into the loader and sandbox system, which we would still like to spec out at some point
[19:26] <kriskowal> i mean, we have implementations, but it would be good for those api's to be interoperable down the line, for implementing other cool stuff. DSL's and DI
[19:28] <kriskowal> so, i tend to think that the best way to deliver simplicity is to have graded layers of complexity, where you can buy more features with some complexity.
[19:28] <isaacs> kriskowal: that's generally my opinion as well.
[19:28] <isaacs> however, the most common case should be both very simple to use, and very debuggable/easy to understand what's going on.
[19:28] <kriskowal> yes
[19:29] <isaacs> if the bug is in the result of require("../foo.js") is pretty dead-simple to guess which file to add the logging code to.
[19:29] <kriskowal> in the simple case, yeah
[19:29] <isaacs> not so much if it's coming out of require("foo") and could be from 7 different paths.
[19:30] <kriskowal> in narwhal, even require("../foo") can come from 7 paths or 3 extensions. i don't think it makes it much harder.
[19:30] <isaacs> also, require("http://foo.com/foo.js") is a lot more obvious than making the http request and then manually evaling it.
[19:30] <kriskowal> and we had considered dot-delimited identifier components, which would have taken us down a very different track
[19:30] <isaacs> yea, i remember some discussion of that.
[19:30] <isaacs> require("foo.bar.baz")
[19:30] <kriskowal> right, which has its own advantages
[19:31] <isaacs> well, yes and no.
[19:31] <kriskowal> particularly forward compatibility with "import foo.bar.baz", where the module name space and the local name spaces collide
[19:31] <isaacs> ugh.
[19:31] <Wes--> kriskowal: require("package-mgr").require("isaacs-awesome-package")
[19:31] <kriskowal> like in most other languages, bear in mind
[19:31] <isaacs> kriskowal: but javascript isn't most other languages! it's better!
[19:31] <kriskowal> peter michaux at some point called us out for waffling, so we made a nearly arbitrary choice for slash delimiters
[19:32] <isaacs> mapping import foo.bar.baz to foo/bar/baz.py adds an element of magic that i'm not comfortable with.
[19:32] <isaacs> better to be explicit.
[19:32] <kriskowal> Wes-- yeah, there are certain advantages to deferring the issue to a module
[19:33] <kriskowal> presumably that expression would return a new require function that grabs modules from just that package
[19:33] <Wes--> kriskowal: The most interesting advantage is that any CommonJS platform with fs-base could run a package manager that was a module
[19:33] <isaacs> kriskowal: really, Wes--'s suggesion there could shut us all up.
[19:34] <isaacs> i mean, then you could just have the implementation provide some kind of package manager (which could work any way it wants), and it'd be fine.
[19:34] <isaacs> if you wanted to port tusk to nodejs, then that's an option, or port npm to narwhal, or whatever.
[19:34] <isaacs> go crazy.
[19:34] <kriskowal> so it changes from an issue of revamping the module system to specifying a package manager API and a module loader API
[19:35] <isaacs> kriskowal: but why even do that?
[19:35] <kriskowal> interoperability
[19:35] <isaacs> why not just say "this is my awesome program. it requires that you use tusk. tusk is available for these platforms. have fun."
[19:35] <kriskowal> so code can be written to target any compliant implementation
[19:35] <isaacs> tusk just has to add require("tusk")
[19:36] <isaacs> just teh same way we use jquery or yui to smooth out the browser differences, we'd use package managers to smooth out the platform differences, and then we'd be free to experiment more and see what's more fun to use.
[19:36] <kriskowal> that still leaves us with the business of specifying the other kind of package, the kind that can add things to the top-level module identifier name space, like tusk
[19:36] <isaacs> and then keep the base commonjs specification as small as possible.
[19:37] <kriskowal> so that an implementation can be shared.
[19:38] <isaacs> kriskowal: maybe then the issue isn't "how do we solve the require() namespace problem", but rather "how do we limit package managers so that they dont' cause a require() namespace problem, and can solve their own namespace problems however they deem best."
[19:40] <kriskowal> while i agree that would make our problem easier to solve, and that it cuts the API into good chunks, i do think we'll need to nail down API details so that code can be used in multiple commonjs compliant implementations
[19:40] <ashb> fwiw i think the package proposal as it stands is overly complex
[19:40] <kriskowal> i agree that it's complex
[19:40] <ashb> but i'm of hte opinion that the package manager could just be a module anyway
[19:40] <isaacs> right.
[19:40] <ashb> p = require('package-mgr').require;
[19:40] <ashb> p('foo'); etc
[19:40] <isaacs> as long as the complexity is tusk's problem, then who cares?
[19:41] <isaacs> ashb: could even be require("package-mgr").loadPackage or whatever it wants to call it.
[19:41] <ashb> isaacs: also not sure if it gont mentioned (i skiped 20mins of backsrol)
[19:41] <ashb> but i htink the camel case restriction is fucking stupid
[19:41] <kriskowal> sorry
[19:41] <isaacs> ashb: i was trying to be more polite, but i agree 110%
[19:41] <kriskowal> that was my mistake
[19:41] <ashb> and i dont know of any thing that actually enforces it
[19:41] <isaacs> ^_^
[19:41] <ashb> so i changed it
[19:41] <ashb> then 1 or 2 people complained vocally
[19:42] <ashb> so i think i'll change it back to at least remove the restriction on camelCase
[19:42] <ashb> since well, it aint a restirction that is enforces
[19:42] <kriskowal> that's a matter of process
[19:42] <ashb> but if i just do it again people might not notice :)
[19:42] <kriskowal> anything with a version number can't be treated as a wiki page anymore; it needs to be a proposal
[19:43] <kriskowal> i'm thinking that the mature specs need to maintained on github hereonout; we can start making that move soon.
[19:43] <kriskowal> then these kinds of problems can be resolved more fluidly as patch proposals
[19:43] <ashb> yeah probably
[19:44] <ashb> so i think the require wording needs extending
[19:44] <kriskowal> i don't object to the change; but i changed it back because anything with "ratified" means that some people agreed on it. it would be dishonest to attribute their agreement to a moving spec.
[19:44] <ashb> to explicitly allow impls to load base on uris or absolute paths(?)
[19:46] <kriskowal> yes. we need to revise the wording to state that interoperable commonjs modules must use the specified identifier style, but that commonjs module loader implementations are free to accept other styles of identifiers
[19:46] <kriskowal> as long as they are a strict super-set of the specified identifier domain
[19:46] <ashb> and also state that require('x.js') must load 'x.js.js' in preference over 'x.js'?
[19:47] <ashb> i.e. not accepting extensions is worded wrong
[19:47] <kriskowal> although, we might regret being so loose. it might be better to extend the spec as an act of civil disobedience, so we can earnestly deprecate those extensions if we decide to narrow it down
[19:47] <ashb> hmmm perhaps
[19:48] <Wes--> kriskowal: agree w.r.t. wording revision
[19:48] <Wes--> ashb: insisting that require("x.js") load x.js.js is good from my POV too
[19:49] <Wes--> Although, I have had funny problems lately because of that
[19:49] <kriskowal> if anyone has time, i recommend copying the specs into the commonjs github project and pushing patches
[19:49] <ashb> probably worded such that 'if `require("x")` would load x.js, then require("x.js") must load x.js.js in preference over x.js"
[19:49] <Wes--> I don't like to name my programs with filenames that end in .js
[19:49] <ashb> so that we dont bake in requiring to search for .js files
[19:49] <Wes--> I don't believe that the implementation language is any business of the person using the program
[19:49] <Wes--> So, I wind up with an interesting problem generating module IDs
[19:49] <kriskowal> Wes-- yes, we use basenames for executables in narwhal
[19:49] <Wes--> a program A and a module A.js could have the module id
[19:49] <kriskowal> the algorithm for handling those cases has become somewhat complicated
[19:50] <ashb> thats why i made module ids in flusspferd file:// uris
[19:50] <ashb> seemed easier
[19:50] <kriskowal> what, the canonical ids?
[19:50] <Wes--> I have started using canonical file names instead
[19:50] <ashb> yeah, thats what i store in module.id
[19:50] <Wes--> Although that has given me minor grief
[19:50] <kriskowal> ashb: in fs-base, is module.id == "fs-base"?
[19:51] <Wes--> It isn't here
[19:51] <ashb> so fs-base is a native module only, so it just as 'fs-base'
[19:51] <kriskowal> but other modules on the paths?
[19:51] <Wes--> although, it is guaranteed to be an argument suitable for loading fs-base
[19:51] <ashb> but a JS file gets its module.id as file:///path/to/file.js
[19:51] <ashb> yeah
[19:52] <Wes--> And I believe that mandating anything more strict than "module ID must be a suitable argument for require" is an error
[19:52] <kriskowal> that'll break things
[19:52] <ashb> what things?
[19:52] <kriskowal> module.id being based on require.paths is a good invariant?
[19:52] <ashb> hmmm?
[19:53] <ashb> so if oyu do require('foo.bar')
[19:53] <Wes--> I don't see how "module.id is unique, and suitable for use by require" is a poor invariant
[19:53] * kriskowal wasn't able to find an example
[19:53] <ashb> i cache it under 'foo.bar' and 'file://path/to/foo/bar.js'
[19:53] <ashb> and either way will igve oyu the same expotrs object
[19:53] <kriskowal> yes, but if you port code from one commonjs implementation to another, the module.id won't be invariant
[19:53] <ashb> why would it matter?
[19:54] <ashb> its not invariant if oyu move it about on disk either
[19:54] <ashb> all that mattres is its invariant in a single run surely?
[19:54] <kriskowal> but it is invariant if the author of the module does nothing
[19:54] <kriskowal> you could make that argument about the order of object properties
[19:55] <kriskowal> in python, dict keys are not guaranteed to be in the same order, since they use memory locations for hashing
[19:55] <ashb> the module id depends on how its loaded
[19:55] <kriskowal> which means that they leak information about the layout of memory. javascript does not, for security reasons
[19:55] <kriskowal> but, if the module.id depends only on the location of the file relative to one of the require.paths, then it is consistent across all commonjs implementations
[19:55] <ashb> for instance require.paths.unshift('dir/lib'); reqiure('foo/bar') vs require.paths.unshift('dir'); require('lib/foo/bar')
[19:55] <ashb> both would load the same module
[19:56] <ashb> module.id is never going be gaunrteed invariant between runs evne
[19:56] <ashb> so if its not invariant between runs, i dont see why it matters *what* value it has
[19:56] <kriskowal> unless you're in a secure sandbox, where futzing with require.paths is either an error or ignored
[19:56] <ashb> yes, but we aren't
[19:57] <kriskowal> so, you're not interoperable with a secure sandbox? hm
[19:57] <ashb> correct. no one is
[19:57] <ashb> there isn't a spec for a secure sandbox yet
[19:57] <kriskowal> the modules proposal is designed to be securable
[19:58] <ashb> i how the behaviour i'm describing is incompattible
[19:58] <kriskowal> it leaks information about the underlying file system
[19:59] <ashb> information leakage does not instantly make it insecure
[19:59] <kriskowal> sure. it makes it a security hazard
[19:59] <kriskowal> which is why we called them securable instead of secure
[19:59] <kriskowal> there's no such thing as secure. there's only asymptotic elimination of security hazards.
[20:00] <ashb> on the other hand, using the path relative only to the module search dir doesn't really work to my mind
[20:00] <ashb> but more importantly
[20:00] <kriskowal> works fine in narwhal
[20:00] <ashb> there is no requirement on what form module.id must take
[20:00] <kriskowal> tho i'll grant for a securable subset of usage
[20:00] <ashb> just that calling require(module.id) must return the module
[20:01] <ashb> and that can and should be implementation specific.
[20:01] <kriskowal> first sentence of Module Context 3.1
[20:01] <kriskowal> it must be equal to the top-level id of the module.
[20:01] <ashb> The "id" property must be such that require(module.id) will return the exports object from which the module.id originated. (That is to say module.id can be passed to another module, and requiring that must return the original module).
[20:02] <ashb> those 2 clash
[20:02] <kriskowal> The "module" object must have a read-only, don't delete "id" property that is the top-level "id" of the module.
[20:02] <kriskowal> no, the second is a strict subset of the first
[20:02] <ashb> only in narwhal it is.
[20:02] <kriskowal> excuse, it's more general
[20:03] <kriskowal> that's verbatim the first sentence of the same bullet point you quoted
[20:03] <ashb> in gpsee, v8cgi and flusspferd where we handle require('./foo') differently a top-level id is only a search indicator, not stricly useful
[20:03] <kriskowal> bbl
[20:04] <ashb> and whats the top level id ofa module wich is outside the search paths?
[20:04] <ashb> require('../../../../../x')
[20:04] <ashb> etc
[20:04] <kriskowal> not defined by the spec
[20:04] <kriskowal> in narwhal, we use canonical paths for those
[20:04] <ashb> but loadable. therefore top-level-ids aren't sufficent to my mind
[20:04] <ashb> so why not use canonical paths always?
[20:04] <kriskowal> not sufficient for extensions, no
[20:04] <kriskowal> to maintain the invariant
[20:04] <ashb> there is no inviariant.
[20:05] <ashb> since the top level id depends on the exact module path
[20:05] <kriskowal> for commonjs compliant modules, that are on the search path, where there's no mention of require.paths being available or useful, it's invariant.
[20:05] <kriskowal> everything else is extensions to the implementations
[20:05] <ashb> 1.6 mentionds require.paths
[20:05] <kriskowal> often useful and necessary
[20:05] <kriskowal> yes, that it "may" exist
[20:06] <kriskowal> but it "must" not exist in others
[20:06] <ashb> so there is no guarnteed invariant in most cases
[20:06] <kriskowal> in some cases
[20:06] <kriskowal> but those cases are well defined
[20:07] <ashb> http://pastie.org/680500
[20:07] <ashb> actualy one sec
[20:08] <ashb> http://pastie.org/680500
[20:08] <kriskowal> yes, i agree that futzing with require.paths can break the invariant
[20:08] <ashb> under your scheme x and z have the same id
[20:09] <ashb> so a top level id IS NOT INVARIANT
[20:09] <ashb> cos if it changes its not exactly invaraitn
[20:09] <kriskowal> it is invariant if you don't futz with require.paths and don't have modules outside the search path
[20:09] <kriskowal> which is the case for any modules that are interoperable
[20:09] <ashb> and what it is not hte module that change the paths but the app
[20:10] <ashb> in a way that is specified
[20:10] <ashb> should the modules break?
[20:11] <kriskowal> i think it's fair to expect redundancy in the module memo if you do that.
[20:11] <ashb> but i still dont get why id invairance (between executions/platforms) even matters to module writers. i can't think of a use case for it
[20:11] <kriskowal> debug messages
[20:11] <ashb> eh?
[20:11] <kriskowal> suppose print(module.id)
[20:11] <kriskowal> then somebody writes a jsdoc doctest
[20:11] <ashb> dont do that - its not an invariant
[20:12] <kriskowal> it should be
[20:12] <ashb> (i know, not an arugment)
[20:12] <ashb> its never guanrteed to be the same between runs though, so how would relying on it be useful?
[20:13] <ashb> my module ids could be 1,2,3
[20:13] <ashb> and then be fully compliant with the spec but be entirely useless
[20:14] <ashb> (as in 3 modules, given sequential ids when they are loaded)
[20:14] <_ry> should require("/usr/local/sys.js") be allowed?
[20:15] <kriskowal> yes
[20:15] <_ry> that is, absolute file system paths?
[20:15] <ashb> _ry: in practice yes
[20:15] <ashb> the spec sohuld allow it, but not require it
[20:15] <kriskowal> they do not collide with the defined domain of module ids
[20:15] <_ry> (or should it be require("file:///usr/local/sys.js") ?)
[20:15] <_ry> (or both?)
[20:15] <kriskowal> but they should not be used in commonjs interoperable modules
[20:15] <ashb> _ry: which ever you prefer
[20:15] <ashb> flusspferd does the file:: route
[20:15] <ashb> ://
[20:15] <kriskowal> we intend to support both in narwhal
[20:16] <kriskowal> down the line.
[20:16] <isaacs> require("file://...) leaves the door open for swapping file:// with http://
[20:16] <ashb> thats why i went that way
[20:17] <kriskowal> at this point, i think i could concede that neither ashb or i have made a compelling argument one way or the other, and that the decision is arbitrary. one one side you have consistent behavior among secure and insecure sandboxes where require.paths does not exist and modules outside the domain do not exist, or you have consisten behavior when you do fiddle with require.paths.
[20:17] <ashb> i'll agree that its all up in the air, certainly :)
[20:17] <Wes--> kriskowal: not ONLY fiddling with require.paths ---- making changes to the underlying filesystem (like adding a new module)
[20:18] <ashb> i think we sohuld at least make a note in the spec that the point is under dicsussion?
[20:18] <kriskowal> i think the note belongs in the Modules article, not in the spec
[20:18] <ashb> modules article?
[20:18] <kriskowal> wiki/Modules vs wiki/Modules/1.1
[20:18] <ashb> /Modules/1.1, ah okay
[20:19] <kriskowal> the former is the discussion and materiel, the latter is the spec
[20:19] <kriskowal> the version-numbered ones need to be handled with care
[20:20] <ashb> k
[20:20] <ashb> i'll add notes about module.id and camelCase
[20:20] <ashb> (to Modules)
[20:20] <kriskowal> but it would be fine to copy it to a proposal page and modify it
[20:22] <ashb> kriskowal: i do wonder why you and i seem ot be on opposite sides so often
[20:23] <ashb> (generally that is)
[20:23] <ashb> tho i do enjoy a good argument
[20:23] <Wes--> Are you both fans of Manchester United?
[20:24] <ashb> eugh football
[20:25] <ashb> http://wiki.commonjs.org/wiki/Modules update
[20:25] <Wes--> You should see what they do in America. They take English football fans -- from opposing teams -- and put them in an octagonal boxing rings
[20:25] <Wes--> they call it "UFC"
[20:26] <Wes--> Ultimate Fighting Championship or something like that. Silliest thing I have ever seen on the Telly
[20:26] <ashb> dont enjoy grown men kicking each other in the head?
[20:27] <Wes--> Not particularly. Frightening thing is, I know people who spend $60 an episode on that tripe.
[20:27] <ashb> $60?
[20:27] <ashb> wow.
[20:27] <ashb> i'm in the wrong business
[22:10] <kriskowal> ashb: you might also want to make a note that those issues require discussion on the status page
[22:10] <kriskowal> and, i don't think we disagree too much
[22:10] <ashb> i mainly just didn't want people taking it as given/final
[22:16] * ashb goes back to hacking on pdoc
[22:24] <evilstreak> what happened to mongo hacking?
[22:25] <ashb> um, it works basically okay enough >_>
[22:26] <ashb> and i need to find someone who knows what API the narwhal/rhino mongodb module has
[22:27] <tlrobinson> ashb: http://github.com/mrclash/narwhal-mongodb
[22:27] <ashb> thanks
[22:28] <evilstreak> going to match the API?
[22:28] <ashb> thinking about it
[22:28] <evilstreak> (assuming you don't find bits of it that annoy you horribly)
[22:29] <ashb> also thinking about maybe matching the mongo shell more closely
[22:30] <ashb> if (require.main === module.id)
[22:30] <ashb> tlrobinson: narwhal hasn't changed require.main to be the module object yet?
[22:31] <ashb> also: assert.isEqual( 100 , c.find().snapshot().limit(50).count() );
[22:31] <ashb> seems odd to me
[22:32] <ashb> i.d expect that to be 50
[22:35] <MisterN> ashb: do you like queries like this one? { "i": { "$gt": 50 } }
[22:35] <ashb> define like
[22:35] <MisterN> i must say i find the syntax to be not particularly convincing.
[22:35] <ashb> thats what mongo uses
[22:37] <MisterN> :/
[22:37] <MisterN> well i guess constantly writing views like couchdb requires isn't that thrilling either
[22:41] <deanlandolt> ashb, MisterN: then you should really give another look to persevere :)
[22:42] <MisterN> link?
[22:42] <deanlandolt> persvr.org
[22:42] <deanlandolt> http://persvr.org/documentation
[22:43] <deanlandolt> ugh... http://docs.persvr.org/documentation/
[22:43] <MisterN> buzzword compliance, *check*
[22:43] <ashb> docs/documentation
[22:43] <deanlandolt> queries are just jsonquery
[22:43] <deanlandolt> heh :)
[22:43] <deanlandolt> rest isn't just a buzzword ;)
[22:43] <ashb> can always easily stick a JSONQuery front end on mongo
[22:44] <deanlandolt> queries are just http calls...there's a shell too
[22:44] <deanlandolt> ashb: true
[22:44] <MisterN> deanlandolt: i was assuming simplifyingly that all the "word links" on the homepage are buzzwords :)
[22:44] <ashb> heheh
[22:44] <deanlandolt> MisterN: no doubt
[22:44] <ashb> probably are
[22:45] <deanlandolt> but the jsonpath/jsonquery syntax is pretty nice
[22:47] <MisterN> deanlandolt: yeah looks better
[22:48] <MisterN> can it be implemented efficiently? :)
[22:48] <ashb> js_namespace.to_a.slice(0..-2).join(".")
[22:48] <ashb> ruby q - what does that to?
[22:48] <ashb> assuing to_a returns an array
[22:48] <ashb> take the first to 3rd to last element?
[22:49] <ashb> [1,2,3,4] -> '1.2' ?
[22:49] <deanlandolt> MisterN: yep...at least a large subset of it
[22:49] <deanlandolt> ashb: i like any rubyfoo but that looks right to me
[22:49] <MisterN> and then there's the fact that i'm bitter about nobody other than me liking RDF :>
[22:50] <ashb> RDF is like lisp right?
[22:50] <deanlandolt> i think the hatred for xml overshadows any nicities rdf brings to the table
[22:50] <MisterN> ashb: huh?
[22:50] <deanlandolt> RDFa looks promising
[22:50] <MisterN> deanlandolt: i like the turtle syntax.
[22:51] <ashb> on no, it was prolog
[22:51] <ashb> my only exposure to RDF was via prolog
[22:51] <MisterN> deanlandolt: http://en.wikipedia.org/wiki/Turtle_%28syntax%29
[22:51] <deanlandolt> MisterN: yeah, just found that...reading now
[22:51] <MisterN> RDFa is unconvincing IMHO
[22:52] <evilstreak> Persevere is Java though. bleh :p
[22:52] <MisterN> ashb: but prolog isn't like lisp at all :)
[22:52] <ashb> no - i remember lots of brackets tho
[22:52] <deanlandolt> evilstreak: kris is rewriting it to be kjs
[22:52] <deanlandolt> s/kjs/js
[22:52] <MisterN> deanlandolt: just using some basic commonjs modules?
[22:53] <ashb> as many as possible, yeah
[22:53] <deanlandolt> right now on top of narwhal, but IIRC he's investigating juice (so, by extension, the hippo)
[22:53] <ashb> win
[22:53] <MisterN> ashb: so the execution model of prolog was not the problem, just the syntax? :)
[22:53] <ashb> its kriszyp right?
[22:53] <deanlandolt> yes
[22:53] <ashb> cool - i should drop him an email
[22:54] <kriszyp> hey ashb
[22:54] <ashb> ah your online
[22:54] <MisterN> deanlandolt: optimally persevere would run on both narwhal and flusspferd :)
[22:54] <kriszyp> yeah, I'm working on getting persvr running on juice, but more the framework part, not the db/storage engine
[22:54] <ashb> yeah that would be the best way
[22:54] <kriszyp> it looks like juice is in pretty good shape for running it though
[22:54] <ashb> heh - framework on a framework \o
[22:55] <MisterN> framework on a framework on an abstraction layer on an interpreter
[22:55] <deanlandolt> kriszyp: is it just jsdb that will stay java, or everything persistence-related?
[22:55] <ashb> for my next trick, i shall run a juic eapp insire persvr which is running on juice
[22:55] <kriszyp> but I kind of was counting on others writing mongodb drivers or connectors to other document dbs to connect to
[22:55] <kriszyp> well, I am just running it on the JSGI server part
[22:55] <MisterN> ashb: that will beat them into submission muhahaha
[22:55] <ashb> kriszyp: like http://github.com/ashb/mongodb-flusspferd etc you mean? :)
[22:56] <kriszyp> is that juice or flusspferd?
[22:56] <ashb> juice sub project
[22:56] <ashb> Zest
[22:56] <kriszyp> awesome
[22:56] <ashb> http://github.com/ashb/Zest that one
[22:56] <deanlandolt> ashb: IIRC kriszyp was shooting for http://www.w3.org/TR/WebSimpleDB/
[22:56] <kriszyp> oh, I am running on zest?
[22:56] <kriszyp> ok
[22:56] <ashb> zest is htat http -> JSGI server, yeah
[22:56] <MisterN> zest in turn is based on boost.asio
[22:57] <MisterN> ashb: it is, right?
[22:57] <kriszyp> yeah, I am working on making adapters that confomr to the websimpledb api so they can be fairly interchangeable in persvr
[22:57] <ashb> MisterN: yeah
[22:57] <kriszyp> boost?
[22:57] * kriszyp is getting confused
[22:57] <ashb> boost is a big C++ library collection
[22:57] <kriszyp> k
[22:57] <MisterN> which includes sockets (= asio)
[22:57] <ashb> kriszyp: i'm in the process of writing API docs etc for all this, which should make it clearer
[22:57] <kriszyp> but when I downloaded juice, and run persvr on top of the jsgi server, I was running on zest, right?
[22:58] <ashb> yeah
[22:58] <ashb> if you look in script/server
[22:58] <ashb> it basically does |server = new Zest({handler: app}); server.start()
[22:58] <ashb> |the cool thing about boost.asio is it can potentially be used to do setTimeout and similar
[22:59] <MisterN> ashb: zest is just a module?
[22:59] <ashb> MisterN: yup
[23:00] <kriszyp> cool, I have some other questions for you too, but I am off to a meeting now...
[23:00] <ashb> cool. if i'm not online (responding) when you come back - ash.berlin@gmail.com
[23:01] <kriszyp> but I am excited to run persvr on top of flusspferd, I think it will be very cool
[23:01] <ashb> or any of the mailing lists
[23:01] <ashb> yeah it will
[23:01] <kriszyp> yep
[23:01] <kriszyp> oops, I mean zest :)
[23:01] <ashb> :D
[23:01] <MisterN> kriszyp: zest uses flusspferd so you were not saying something wrong :)
[23:01] <deanlandolt> it's zest on juice on flusspferd...right?
[23:02] <ashb> zest is juice's development server
[23:02] <ashb> (zest = skin of a citrus fruit, i.e. the bondary of juice)
[23:02] <deanlandolt> oh...okay...so it's really just zest on flusspferd with boost? :)
[23:02] <MisterN> deanlandolt: hmm i think it's (juice + zest) on flusspferd, but not sure
[23:02] <ashb> Juice is a webapp framework built on pure JSGI
[23:02] <ashb> you can use it without zest
[23:03] <deanlandolt> gotcha
[23:03] <deanlandolt> so it'd probably just be persvr on zest...it wouldn't really use juice
[23:03] <ashb> which I command you to all go and use.
[23:03] <deanlandolt> alright..i think i'm all strait :)
[23:03] <deanlandolt> ashb: i started poking around...took me no time at all to get up and going
[23:03] <MisterN> deanlandolt: do you like the turtle syntax btw? :)
[23:03] <ashb> deanlandolt: that was the idea
[23:04] <deanlandolt> MisterN: it's less...abrasive, i must say
[23:05] <deanlandolt> i must admit i'm not a big fan of learning new data formats...it's hard enough to keep with what's there now
[23:05] <deanlandolt> but some years ago a bunch of semantic web academics convinced me of RDF's utility...i've been waiting for it to take off
[23:06] <MisterN> hasn't happened since :/
[23:06] <MisterN> deanlandolt: in fact, musicbrainz for example even backpedalled
[23:06] <deanlandolt> yeah, and i'm glad they did
[23:06] <MisterN> why?
[23:06] <deanlandolt> i've scraped their api a few times
[23:06] <deanlandolt> i couldn't figure out how to use it
[23:07] <deanlandolt> i remember a big ol datadump with tagsoup and wanted to cry
[23:08] <deanlandolt> now it's still crappy xml but imho Sucks Less
[23:08] <ashb> JSO apis are the future
[23:08] <ashb> JSON
[23:08] <deanlandolt> i don't know...i'm a big believer that language-agnostic apis are the future
[23:08] <ashb> JSON is language agnostic
[23:09] <deanlandolt> rather, grammer-agnostic
[23:09] <deanlandolt> as crock said in a presentation about json, it's the intersection of all languages
[23:09] <deanlandolt> xml, on the other hand, is the union
[23:09] <deanlandolt> so json (plus extensions, like json referencing and jsonschema in particular) shows us the way...
[23:09] <MisterN> funnily, JSON is a subset of the formerly-popular YAML :)
[23:09] <deanlandolt> but that doesn't mean it's the only way
[23:10] <deanlandolt> MisterN: yep
[23:10] <MisterN> deanlandolt: RDF would be language-agnostic :>
[23:10] <deanlandolt> yeah...that's why i'd like to see a JSON RDF grammer :)
[23:10] <MisterN> it's even possible to do it on JSON, though not really fun
[23:10] <MisterN> deanlandolt: but there is.
[23:10] <deanlandolt> really? ooh
[23:11] <MisterN> http://n2.talis.com/wiki/RDF_JSON_Specification
[23:11] <deanlandolt> ouch...no namespace prefixes make it pretty awkward
[23:12] <MisterN> that's the problem :)
[23:13] <MisterN> deanlandolt: but with namespace prefixes it would be harder to parse
[23:13] <deanlandolt> that's where json referencing would be useful
[23:13] <MisterN> deanlandolt: RDF/JSON is nice for interchange between computers i think
[23:14] <deanlandolt> i'm sure it's good enough...i'd prefer to parse this than rdf/xml
[23:16] <deanlandolt> MisterN: oh, so Turtle's pretty close to SPARQL in syntax...i guess that makes it less foreign (given you'd have to learn SPARQL to do anything useful with RDF)
[23:18] <MisterN> deanlandolt: i actually find it to be close to JSON too :)
[23:18] <deanlandolt> i guess it's not too far off
[23:23] <deanlandolt> MisterN: what kind of performance can you get out of something like sparql for typical rdbms-style set operations?
[23:24] <deanlandolt> isn't it pretty expensive to walk the graph? or has it been optimized to death?
[23:28] <MisterN> deanlandolt: no, not at all. i think it only shines when you aren't able to specify a fixed schema.

 

 

Logs by date :

• 2010-03-14
• 2010-03-13
• 2010-03-12
• 2010-03-11
• 2010-03-10
• 2010-03-09
• 2010-03-08
• 2010-03-07
• 2010-03-06
• 2010-03-05
• 2010-03-04
• 2010-03-03
• 2010-03-02
• 2010-03-01
• 2010-02-28
• 2010-02-27
• 2010-02-26
• 2010-02-25
• 2010-02-23
• 2010-02-22
• 2010-02-21
• 2010-02-20
• 2010-02-19
• 2010-02-18
• 2010-02-16
• 2010-02-15
• 2010-02-14
• 2010-02-13
• 2010-02-12
• 2010-02-11
• 2010-02-10
• 2010-02-09
• 2010-02-08
• 2010-02-07
• 2010-02-06
• 2010-02-05
• 2010-02-04
• 2010-02-03
• 2010-02-02
• 2010-02-01
• 2010-01-31
• 2010-01-30
• 2010-01-29
• 2010-01-25
• 2010-01-24
• 2010-01-23
• 2010-01-22
• 2010-01-21
• 2010-01-20
• 2010-01-19
• 2010-01-18
• 2010-01-17
• 2010-01-16
• 2010-01-15
• 2010-01-14
• 2010-01-13
• 2010-01-12
• 2010-01-11
• 2010-01-10
• 2010-01-09
• 2010-01-08
• 2010-01-07
• 2010-01-06
• 2010-01-05
• 2010-01-04
• 2010-01-03
• 2010-01-01
• 2009-12-31
• 2009-12-30
• 2009-12-29
• 2009-12-27
• 2009-12-26
• 2009-12-25
• 2009-12-24
• 2009-12-23
• 2009-12-22
• 2009-12-21
• 2009-12-20
• 2009-12-19
• 2009-12-18
• 2009-12-17
• 2009-12-16
• 2009-12-15
• 2009-12-14
• 2009-12-13
• 2009-12-12
• 2009-12-11
• 2009-12-10
• 2009-12-09
• 2009-12-08
• 2009-12-07
• 2009-12-06
• 2009-12-05
• 2009-12-04
• 2009-12-03
• 2009-12-02
• 2009-12-01
• 2009-11-30
• 2009-11-24
• 2009-11-23
• 2009-11-22
• 2009-11-20
• 2009-11-19
• 2009-11-18
• 2009-11-17
• 2009-11-16
• 2009-11-15
• 2009-11-14
• 2009-11-13
• 2009-11-12
• 2009-11-11
• 2009-11-10
• 2009-11-09
• 2009-11-08
• 2009-11-07
• 2009-11-06
• 2009-11-05
• 2009-11-04
• 2009-11-03
• 2009-11-02
• 2009-11-01
• 2009-10-31
• 2009-10-30
• 2009-10-29
• 2009-10-28
• 2009-10-27
• 2009-10-26
• 2009-10-25
• 2009-10-24
• 2009-10-23
• 2009-10-22
• 2009-10-21
• 2009-10-20
• 2009-10-19
• 2009-10-17
• 2009-10-16
• 2009-10-15
• 2009-10-14
• 2009-10-13
• 2009-10-12
• 2009-10-11
• 2009-10-10
• 2009-10-09
• 2009-10-08
• 2009-10-05
• 2009-10-04
• 2009-10-07
• 2009-10-03
• 2009-10-02
• 2009-10-01
• 2009-10-06
• 2009-09-30
• 2009-09-29
• 2009-09-28
• 2009-09-27
• 2009-09-26
• 2009-09-25
• 2009-09-24
• 2009-09-23
• 2009-09-22
• 2009-09-21
• 2009-09-20
• 2009-09-19
• 2009-09-18
• 2009-09-17
• 2009-09-16
• 2009-09-15
• 2009-09-14
• 2009-09-13
• 2009-09-12
• 2009-09-11
• 2009-09-10
• 2009-09-09
• 2009-09-08
• 2009-09-07
• 2009-09-06
• 2009-09-05
• 2009-09-04
• 2009-09-03
• 2009-09-02
• 2009-09-01
• 2009-08-31
• 2009-08-30
• 2009-08-29
• 2009-08-28
• 2009-08-27
• 2009-08-26
• 2009-08-25
• 2009-08-24
• 2009-08-23
• 2009-08-22
• 2009-08-21
• 2009-08-20
• 2009-08-19
• 2009-08-18
• 2009-08-17
• 2009-08-15
• 2009-08-13
• 2009-08-12
• 2009-08-11
• 2009-08-10
• 2009-08-08
• 2009-08-07
• 2009-08-03
• 2009-08-01
• 2009-07-31
• 2009-07-30
• 2009-07-29
• 2009-07-28
• 2009-07-27
• 2009-07-26
• 2009-07-25
• 2009-07-24
• 2009-07-23
• 2009-07-22
• 2009-07-21
• 2009-07-20
• 2009-07-19
• 2009-07-18
• 2009-07-17
• 2009-07-16
• 2009-07-15
• 2009-07-14
• 2009-07-13
• 2009-07-12
• 2009-07-11
• 2009-07-10
• 2009-07-09
• 2009-07-08
• 2009-07-03
• 2009-07-02
• 2009-07-01
• 2009-06-30
• 2009-06-25
• 2009-06-24
• 2009-06-23
• 2009-06-22
• 2009-06-21
• 2009-06-18
• 2009-06-17
• 2009-06-16
• 2009-06-15
• 2009-06-13
• 2009-06-12
• 2009-06-11
• 2009-06-10
• 2009-06-09
• 2009-06-08
• 2009-06-07
• 2009-06-06
• 2009-06-05
• 2009-06-04
• 2009-06-02
• 2009-06-01
• 2009-05-31
• 2009-05-29
• 2009-05-28
• 2009-05-27
• 2009-05-26
• 2009-05-25
• 2009-05-24
• 2009-05-23
• 2009-05-22
• 2009-05-21
• 2009-05-20
• 2009-05-19
• 2009-05-18
• 2009-05-17
• 2009-05-16
• 2009-05-15
• 2009-05-14
• 2009-05-13
• 2009-05-12
• 2009-05-11
• 2009-05-09
• 2009-05-08
• 2009-05-07
• 2009-05-06
• 2009-05-05
• 2009-05-04
• 2009-05-03
• 2009-05-02
• 2009-05-01
• 2009-04-30
• 2009-04-28
• 2009-04-27
• 2009-04-26
• 2009-04-25
• 2009-04-24
• 2009-04-23
• 2009-04-22
• 2009-04-21
• 2009-04-19
• 2009-04-18
• 2009-04-17
• 2009-04-16
• 2009-04-15
• 2009-04-14
• 2009-04-13
• 2009-04-12
• 2009-04-11
• 2009-04-10
• 2009-04-09
• 2009-04-08
• 2009-04-07
• 2009-04-06
• 2009-04-05
• 2009-04-03
• 2009-04-02
• 2009-04-01
• 2009-03-31
• 2009-03-30
• 2009-03-29
• 2009-03-28
• 2009-03-27
• 2009-03-26
• 2009-03-25
• 2009-03-23
• 2009-03-20
• 2009-03-19
• 2009-03-18
• 2009-03-17
• 2009-03-15
• 2009-03-14
• 2009-03-13
• 2009-03-12
• 2009-03-11
• 2009-03-10
• 2009-03-09
• 2009-03-08
• 2009-03-07
• 2009-03-06
• 2009-03-05
• 2009-03-04
• 2009-03-03
• 2009-03-02
• 2009-03-01
• 2009-02-27
• 2009-02-26
• 2009-02-25
• 2009-02-23
• 2009-02-22
• 2009-02-21
• 2009-02-19
• 2009-02-18
• 2009-02-17
• 2009-02-16
• 2009-02-15
• 2009-02-14
• 2009-02-13
• 2009-02-12
• 2009-02-11
• 2009-02-10
• 2009-02-09
• 2009-02-08
• 2009-02-07
• 2009-02-06
• 2009-02-05
• 2009-02-04
• 2009-02-03
• 2009-02-02
• 2009-02-01
• 2009-01-31
• 2009-01-30