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

2009-04-08:

[0:00] <dangoor> http://www.toolness.com/wp/?p=441
[0:00] <dangoor> Atul mentions a Creole parser there
[0:01] <ashb> as a general rule thinks like 'remove(path, true)' (passing true or false as a parameter) are really unclear what they mean
[0:01] <MisterN> keyword params ftw
[0:01] <dangoor> anyhow, when the time comes that I'm actually getting the site together, I'll find something that seems to have a decent format and ideally is in JS (but that's not a requirement)
[0:02] <ashb> dangoor: yeah http://www.ivan.fomichev.name/2008/04/javascript-creole-10-wiki-markup-parser.html
[0:02] <ashb> i had problems with that one
[0:02] <MisterN> hmm
[0:02] <ashb> let me remember what
[0:02] <MisterN> dangoor: maybe simply use XHTML for the spec? :D
[0:02] <ashb> here's a shocking idea. plain text!
[0:02] <dangoor> MisterN: that's too obvious ;)
[0:03] <dangoor> ashb: there's no such thing as plain text
[0:03] <MisterN> ashb: plain text has no hyperlinks :)
[0:03] <ashb> psh. RFCs dont need hyperlinks
[0:03] <ashb> >_>
[0:03] <ashb> dangoor: oh its list handling is a bit funny
[0:05] <ashb> "**\nfoo" vs "* *\nfoo" vs "* *\n\nfoo"
[0:05] <MisterN> i know a great way of choosing a spec format: diff-a-bility
[0:05] <ashb> see. plain test is looking better and better >_>
[0:06] <dangoor> MisterN: that's actually why plain text formats are a bit more pleasant than XHTML
[0:06] <MisterN> heh. maybe plain text and create a simple preprocessor that converts links to clickable links
[0:06] <kriskowal> dangoor: creole could be acceptable.
[0:07] <kriskowal> i don't think we'd regret it in the short term, anyway.
[0:07] <dangoor> undefined plain text is not good, because the formatting is less than ideal
[0:07] <ashb> plain text wasn't really a serious suggestion
[0:08] <ashb> i'm just being a fool
[0:08] <dangoor> creole, markdown and restructured text all seem reasonable
[0:08] <ashb> i think i might brefer creole if only it had inline code blocks
[0:08] <ashb> `foo` style
[0:08] <MisterN> i suggest: NOT textile
[0:08] <MisterN> textile = teh sucks
[0:09] <dangoor> MisterN: yeah, I've never been a textile fan
[0:09] <ashb> and markdowns syntax isn't quite memorable enough for me
[0:09] <ashb> i always have to look up how to do links
[0:09] <MisterN> heh
[0:10] <MisterN> oh and the format should have a PDF creator, for shininess
[0:10] <ashb> eh.
[0:10] <ashb> http://princexml.com
[0:10] <ashb> done
[0:10] <dangoor> too princely for my wallet ;)
[0:11] <kriskowal> well, rst does pdf
[0:11] <dangoor> restructuredtext can do PDF
[0:11] <MisterN> does rst have escaping?
[0:11] <dangoor> if I go with rst, I can also use sphinx
[0:11] <kriskowal> it gets points from me too since that's what i've been writing my jsdocs in
[0:11] <MisterN> (proper escaping)
[0:11] <dangoor> http://sphinx.pocoo.org
[0:11] <ashb> dangoor: there's a free version if you dont mind the watermark i istr
[0:11] <kriskowal> escaping? like teletype code inlines?
[0:12] <kriskowal> yes: ``function() {}``
[0:12] <MisterN> like "\n"
[0:12] <kriskowal> and blocks with :: followed by indented code
[0:12] <MisterN> or `` without formatting
[0:12] <MisterN> i mean, just escaping the format sequences...
[0:12] <MisterN> that's an obvious requirement
[0:13] <kriskowal> they're supported, but not particularly memorable
[0:19] <MisterN> if they can be found in the documentation, then that's at least better than textile :)
[0:26] <MisterN> kriskowal: "A backslash followed by any character (except whitespace characters) escapes that character. The escaped character represents the character itself, and is prevented from playing a role in any markup interpretation. The backslash is removed from the output. A literal backslash is represented by two backslashes in a row (the first backslash "escapes" the second, preventing it being interpreted in an "escaping" role)."
[0:26] <ashb> oh btw- thoughts on http://github.com/ashb/template/tree/master appreciated
[0:26] <MisterN> so that's actually quite memorable
[0:27] <MisterN> my vote would go for rst, too
[0:27] <ashb> i think i'd prefer creole over rst
[0:27] <kriskowal> hah, no kidding. didn't realize it was that normal
[0:27] <MisterN> ashb: how does creole do escaping?
[0:28] <MisterN> but rst has pdf, so that's an advantage, heh
[0:28] <kriskowal> sepuku hahaha!
[0:28] <ashb> okay - a modified creole
[0:28] <MisterN> ashb: rst :P
[0:28] <ashb> since crele also doesn't have inline code
[0:28] <ashb> MisterN: rst doesn't quite sit with me
[0:28] <ashb> but that might be the lack of sleep talkig
[0:28] <MisterN> why? it has escaping
[0:28] <MisterN> what more do you want?!
[0:28] <MisterN> lol
[0:29] <ashb> a syntax that i like?
[0:29] <kriskowal> rst grew on me. i was a moinmoin fan before
[0:30] <kriskowal> moinmoin's a lot more like creole, or vis versa i presume
[0:30] <MisterN> i like the rst syntax, actually
[0:30] <ashb> its :: for starting code blocks strikes me as really odd
[0:30] <ashb> thats the only thing i dont like really
[0:30] <MisterN> because it's so close to plain text heh
[0:31] <ashb> who came up with the idea of implicitly binding functions
[0:31] <ashb> and how the fuck do you even implement that sort of thing with spider monkey
[0:31] <ashb> (http://code.google.com/p/interoperablejs/source/browse/trunk/compliance/method/a.js)
[0:31] <MisterN> ashb: doing what?
[0:31] <ashb> http://code.google.com/p/interoperablejs/source/browse/trunk/compliance/method/program.js
[0:31] <dangoor> ashb: for the record, I don't actually like rst as much as markdown or creole, either.
[0:31] <kriskowal> that test verifies that you don't implicitly bind functions
[0:31] <dangoor> but it is well-specified, powerful and has a good collection of tools
[0:31] <ashb> oh yeah. duhh
[0:31] <ashb> i've been in the office for 12hours today
[0:32] <ashb> so i'm probably 1) not as alert as i should be, and 2) more abrasive than normal
[0:32] <kriskowal> sounds like a day that ends with -ay to me.
[0:32] <ashb> *and* the club we wanted to go to was shut
[0:32] <ashb> at 12:30 on a tuesday. poor planing if you ask me
[0:32] <MisterN> ashb: oh you're not working anymore? :D
[0:32] <ashb> not right now no
[0:33] <MisterN> it's late
[0:33] <ashb> yes it is
[0:33] <kriskowal> it's "miller-time" here. one nice thing about being in the office 'til 2 was i was able to catch ondras in prague time.
[0:34] <dangoor> i'm off to the gym. too much sitting
[0:34] <MisterN_> kriskowal: where are you?
[0:35] <kriskowal> ca
[0:35] <MisterN_> and isn't prague in GMT+1?
[0:35] <kriskowal> los angeles area, pasadena
[0:35] <MisterN_> kriskowal: ca.. one of the few state abbreviations that i know
[0:35] <kriskowal> i think maybe +2 or +3
[0:36] <kriskowal> and you?
[0:36] <MisterN_> no prague is GMT+1
[0:36] <kriskowal> ah
[0:36] <MisterN_> http://www.google.com/search?q=timezone+prague
[0:36] <MisterN_> kriskowal: i'm in germany, so GMT+1
[0:37] <kriskowal> i see.
[0:37] <kriskowal> europe's a lot bigger in my head than it is in meatspace, alas
[0:37] <MisterN_> "meatspace"?
[0:37] <MisterN_> europe is very big in IRC :D
[0:38] <kriskowal> yeah. the dimension in which meat exists.
[0:38] <kriskowal> as opposed to the internet.
[0:38] <MisterN_> meat being the most relevant thing outside the internet? :D
[0:39] <kriskowal> not so much, it's just one thing that's definitely not in a computer...yet
[0:39] <MisterN_> europe is also densely populated
[0:39] <MisterN_> so...
[0:40] <MisterN_> not as dense as parts of asia tho
[0:40] <kriskowal> oh, right. prague is south of berlin and east of munich.
[0:40] <kriskowal> so, you'd have to be in the same zone
[0:40] <MisterN_> well that doesn't really matter
[0:40] <kriskowal> i've only been in your nick of the woods on one occasion
[0:41] <MisterN_> i mean, if you look at the timezone map...
[0:41] <kriskowal> yeah, there are parts of arizona, on the amerind reservations, where daylight savings is not observed, so you can cross the street and the time changes.
[0:41] <MisterN_> lol
[0:42] <MisterN_> china also has a single timezone
[0:42] <kriskowal> interesting
[0:43] <MisterN_> yeah it's not very consistent always
[0:44] <MisterN_> we should simply use seconds since the epoch :>
[1:09] <MisterN_> i think git is probably a nice way of collaborating on the spec :)
[1:10] <kriskowal> i concur
[1:10] <ashb> git ftw
[1:17] <MisterN_> Wes: you still here? i have a question about gpsee
[1:19] <ashb> almost home!
[1:22] <MisterN_> ashb: train?
[1:22] <ashb> yeah
[1:22] <ashb> was in late
[1:22] <ashb> on way home
[1:49] <kriskowal> dangoor, it's a really great idea to start managing the specifications in git soon. i think that could spawn a new level of participation. also, rst and creole both have great and exclusive merits.
[1:49] <kriskowal> just to summarize, creole will be easier to port from the wiki, and there are native javascript parsers that could be projects for the standard library.
[1:49] <dangoor> kriskowal: assuming I finish my Bespin work for the week, next week is JS week for me
[1:50] <dangoor> yeah, the ideal is to use a JS toolset
[1:50] <kriskowal> rst is pretty easy to make pdf's from, but also is implemented in python and not in the python standard lib
[1:50] <dangoor> but I don't want that ideal to get in the way of getting the more important stuff done
[1:50] <kriskowal> it's also pretty complicated
[1:50] <kriskowal> to implement, that is.
[1:50] <dangoor> rst handles a lot more formatting cases than typical wiki markup
[1:50] <kriskowal> yeah, just wanted to summarize the trade-offs
[1:50] <kriskowal> yeah
[1:51] <dangoor> PDF is not critical path, imho
[1:51] <kriskowal> right, but you mention the other parts of its toolchain
[1:51] <dangoor> if I need a PDF. I can concatenate the generated HTML and then Save As PDF on my Mac :)
[1:51] <kriskowal> :)
[1:51] <dangoor> I do like Sphinx
[1:51] <kriskowal> yeah, it's pretty good.
[1:52] <dangoor> but a simple, task-specific site generator built around Creole is likely not too hard
[1:52] <kriskowal> rst is also pretty flexible. i added some custom `backtick` reference tags
[1:52] <kriskowal> :module:`file` for example
[1:53] <dangoor> are you going to jsconf?
[1:53] <kriskowal> alas, list was full.
[1:53] <dangoor> ahh, bummer
[1:54] <kriskowal> yeah, i would have liked to meet some of the folks in the community
[1:54] <kriskowal> and i sat on the call for papers for ajaxian too long
[1:59] <MisterN_> dangoor: i think rst is better
[1:59] <MisterN_> if only because it supports escaping
[2:03] <dangoor> MisterN_: couldn't you just wrap whatever it is you want to show in {{{}}}
[2:03] <MisterN_> dangoor: i hate poor escaping
[2:03] <dangoor> though I guess that's preformatted and not just nowiki
[2:04] <MisterN_> many wikis have no escaping at all
[2:04] <MisterN_> and creole seems among them.
[2:04] <dangoor> http://www.wikicreole.org/wiki/Creole1.0#section-Creole1.0-EscapeCharacter
[2:05] <dangoor> odd. the page with the title All Markup on the creole site does not actually seem to include all markup
[2:34] <kriskowal> here's the proposal for the sys variable https://wiki.mozilla.org/ServerJS/System
[2:34] <kriskowal> about to post it to the list
[6:08] <zumbrunn> did I miss the convincing argument against "sys as a module"?
[6:08] <zumbrunn> or, in other words...
[6:08] <zumbrunn> do I read "or inserted into a module scope by some other means" correctly, to mean that it *could* be loaded as a module?
[6:09] <zumbrunn> or does the proposal say that sys is not a module?
[6:10] <zumbrunn> and why can't the proposal say that sys *must* be a module?
[6:12] <ondras> module does not imply a fixed name
[6:12] <ondras> the "sys" proposal states that [global.]sys is always available
[6:12] <ondras> (at least I understand it this way)
[6:13] <tlrobinson> not necessarily global
[6:14] <zumbrunn> in my current thinking, sys would ideally be loaded like any other module, except that it gets loaded into the global object before the global object gets handed to the module
[6:14] <zumbrunn> I don't yet understand why this isn't a) the best and b) always possible
[6:15] <ondras> I believe that this is up to the implementation?
[6:15] <ondras> the spec just states that everyone will have a fixed place, sys.*, to access some basic stuff
[6:16] <zumbrunn> and in which way is that different from any other module that we will define?
[6:16] <tlrobinson> it will always be available
[6:17] <tlrobinson> you don't have to explicitly require it
[6:18] <zumbrunn> what does it help if it is always available, if it isn't available in the same place?
[6:18] <zumbrunn> (not always at global.sys)
[6:18] <ondras> it will be always in the same place, I believe
[6:18] <tlrobinson> yeah, sys
[6:18] <tlrobinson> in a "secured" module it will be passed in the function like function(require, sys) { ... }
[6:18] <tlrobinson> rather than global
[6:20] <zumbrunn> hmm
[6:21] <ondras> why is there such a strong enthusiasm for "secured" modules, when we want to standardize server-side js where no "alien" modules are executed in our scope?
[6:21] <ondras> (as opposed to problematic client side)
[6:21] <zumbrunn> I for one have a strong interest in running untrusted code on the server-side
[6:21] <tlrobinson> ondras: say you want to run some untrusted code on the server in a sandbox
[6:21] <zumbrunn> always had
[6:22] <ondras> tlrobinson: what motivates me to do that? Is there some parallel with existing ss languages and typical usage scenarios?
[6:22] <tlrobinson> for example, an AppEngine like service
[6:22] <zumbrunn> I've been running "semi-trusted" js code on the server-side for a decade
[6:22] <ondras> (/me never encountered such need)
[6:23] <tlrobinson> btw, anyone see AppEngine now supports Java
[6:23] <tlrobinson> http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html
[6:23] <zumbrunn> it's code that "customers" can modify via the browser
[6:23] <tlrobinson> AppEngine + Rhino...
[6:23] <zumbrunn> oh, nope hadn't seen that
[6:23] <zumbrunn> thanks for the pointer
[6:23] <tlrobinson> sign up quickly, only 10000 spots for the beta
[6:24] * ondras still does not get the idea
[6:24] <ondras> I understand that a customer writes his own unsecured code
[6:24] <ondras> but
[6:25] <ondras> how does that gets mixed with other customer's code?
[6:25] <ondras> these are executed independently
[6:25] <ondras> (thinking about cheap php hosting for example...)
[6:25] <tlrobinson> well, you don't necessarily want the customer to have access to the entire filesystem either
[6:26] <tlrobinson> and they aren't necessarily executed in seaprate processes
[6:26] <zumbrunn> yes, I want to be able to protect the customer from screwing up his own application
[6:27] <ondras> okay, so I must provide him with some better IO stuff, which takes care about credentials at higher-than-traditional level
[6:27] <ondras> (traditional = unix process-based rights)
[6:28] <zumbrunn> no, I only want the customer to be able to fiddle with certain js objects inside the running application
[6:28] <zumbrunn> and I want the customer to be able to do that using js
[6:29] <zumbrunn> we are potentially talking about "sandboxes" that are only as big as a small snippet of code
[6:30] * ondras is soo locked in his php-based scenario that he could not see the point :/
[6:48] <ondras> ondras@kapitan:~/svn/v8cgi$ ./runtest.sh cyclic
[6:48] <ondras> [pass] PASS a exists
[6:48] <ondras> [pass] PASS b exists
[6:48] <ondras> [pass] PASS a gets b
[6:48] <ondras> [pass] PASS b gets a
[6:48] <ondras> [info] DONE
[6:48] <ondras> oh yes!!!
[6:48] <ondras> :>
[6:49] * ondras passes all compliance tests :D
[6:49] <ondras> kriskowal: ^ :>
[7:53] <kriskowal_> i've created a new proposal for binary data https://wiki.mozilla.org/ServerJS/Binary/B and reorganized the main page to reflect the current state of affairs https://wiki.mozilla.org/ServerJS/Binary
[11:09] <ashb> kriskowal: 'for the byte in the given position, or undefined'
[11:09] <ashb> when would it return undefined?
[11:11] <ashb> kriskowal: or rather - where should i comment on it?
[11:30] <ashb> ah message on the list
[11:30] <ashb> composing
[12:27] <Wes> MisterN: Back now, FWIW! :)
[12:29] <MisterN> Wes: good. i have this question: how can i attain compatibility with gpsee without creating a dependency on gpsee?
[12:29] <MisterN> Wes: (regarding the module bit)
[12:33] <Wes> MisterN: *without* creating a dependency? Two ways:
[12:33] <Wes> 1) copy load_module.c in its entirety and tweak it to work in your environment
[12:33] <Wes> 2) use the same strategy for loading modules
[12:34] <MisterN> well i thought of using dlsym for finding the gpsee entry points
[12:34] <Wes> the strategy for module loading is outlined in the hacking document I posted a link to yesterday, did you have a chance to read it?
[12:34] <MisterN> and if these are available, use the gpsee strategy
[12:34] <MisterN> Wes: yes i did read it but i'm not sure i understood 100%
[12:34] * Wes is catching up on reading #serverjs from yesterday, wow, busy!
[12:35] <Wes> MisterN: That would work. In fact, you could dlopen() libgpsee.so and use load_module. Hm, no. That won't work.
[12:35] <MisterN> why not?
[12:35] <Wes> The gpsee module loader as it stands now depends on some private data structures etc which are in rt->private
[12:36] <MisterN> oh
[12:36] <Wes> What WOULD work is also starting your javascript interpreter with gpsee if its available
[12:36] <Wes> *digging*
[12:37] <Wes> http://www.page.ca/~wes/opensource/gpsee/docs/source/gpsee_8c-source.html#l00534
[12:38] <Wes> take a look at this, that's how I start a gpsee interpreter
[12:39] <MisterN> flusspferd right now has an interpreter singleton *scratch head*
[12:39] <Wes> There's also a few other gpsee features which modules might want to take advantage of, such as callback multiplexing
[12:39] <MisterN> ca-what?
[12:40] <Wes> interpreter singleton is no big deal; the gpsee API is really just an overlay of spdiermonkey
[12:41] <Wes> say you have two modules that need to hook the operation callback (similar to branch callback in jsapi <= 1.8.0). gpsee handles registering multiple branch callbacks and feeding them to the handlers... that sort of thing.
[12:41] <MisterN> JS_BeginRequest(cx); /* Request stays alive as long as the interpreter does */
[12:41] <MisterN> oO
[12:42] <Wes> for example, my thread class and signals class both need that callback. Threads use it to kick off a sweep for joined threads, signal class uses it process received signals in JavaScript
[12:42] <MisterN> Wes: flusspferd doesn't support hooking the branch callback yet.
[12:42] <Wes> MisterN: you need either the branch callback or the operation callback to support things like signal handlers written in javascript
[12:43] <MisterN> well :)
[12:43] <Wes> does flusspferd have a GC strategy other than wait-for-last-ditch?
[12:43] <MisterN> flusspferd lets spidermonkey do the GC
[12:43] <MisterN> there's a function wrapping JS_GC.. but otherwise it just lets it be
[12:44] <Wes> That's going to be a problem with non-trivial programs; spidermonkey won't do the GC until it runs out of memory
[12:44] <ashb> i thought it ran GC after so many bytes were allocated
[12:44] <Wes> you need to schedule either a regular event with signals or use a thread-safe build to run JS_GC
[12:45] <Wes> ashb: I don't think it will run GC until you hit rt->maxBytes causing an allocation for a gcthing to fail
[12:45] <ashb> Wes: https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_NewRuntime
[12:45] <Wes> (I could be wrong, but I think I'm right)
[12:45] <ashb> and max bytes is usally quite low isn't it?
[12:45] <ashb> like suggested at 8k or something?
[12:46] <ashb> oh no thats the stackchunksize i'm thinking of
[12:46] <MisterN> Wes: does gpsee have a git or svn or something?
[12:46] <Wes> I think that's the total size of your js heap! The description there is kind of poor; I think that's max size, and if you hit it, your GC had BETTER find some ram or your application is done.
[12:46] <ashb> Wes: i dont think that is it
[12:47] <ashb> set it really low and try :)
[12:47] <Wes> mistern: http://kenai.com/hg/gpsee~src
[12:47] <MisterN> Wes: oh, hg. i hope it works with my oold version of hg
[12:47] <Wes> I'll ask in #jsapi later today to see if the recommended gc strategy has changed
[12:47] <Wes> mistern: mine is 1.0 lol
[12:47] <ashb> man. i forgot how painful the spidermonkey API is to use
[12:48] <MisterN> $ hg --version
[12:48] <MisterN> *** failed to import extension hgext.hbisect: No module named hbisect
[12:48] <MisterN> Mercurial Distributed SCM (version 1.1.2)
[12:48] <MisterN> weird
[12:48] <MisterN> ashb: cause you have our nice abstractions :D
[12:48] <ashb> yeah
[12:49] <ashb> Wes: have you happened to create custom subclasses of Error yet?
[12:49] <MisterN> Wes: what's the hg clone line for gpsee exactly? :D
[12:49] <Wes> "ah": By default, the JavaScript engine performs garbage collection when it has no other choice except to grow the process. This means that garbage collection typically happens when memory-intensive code is running, perhaps the worst possible time. An application can trigger garbage collection at a more convenient time by calling JS_GC or JS_MaybeGC. JS_GC forces garbage collection....
[12:50] <Wes> ...JS_MaybeGC performs garbage collection only if it is likely to reclaim a worthwhile amount of memory.
[12:50] <Wes> Perhaps I'm thinking of a performance issue more than anything. (FWIW I disabled my regular GCs because they depended on the branch callback)
[12:51] <Wes> MisterN: I think you have a bad hg configuration, did you add something about bisect in your .hgrc?
[12:51] <Wes> ashb: No, been meaning to.
[12:51] <Wes> ashb: I throw strings, which believe it or not, have been more than enough thus far.
[12:51] <MisterN> Wes: i have no .hgrc
[12:51] <Wes> MisterN: hg clone https://hg.kenai.com/hg/gpsee~src
[12:51] <Wes> mistern: Wierd. I'm still ~new to hg
[12:52] <Wes> http should work if you don't have python ssl support, but you won't be able to push
[12:52] <Wes> oh right, you NEED http if you don't have a kenai account
[12:52] <MisterN> ok i have gpsee~src now :)
[12:53] <Wes> minor warning -- I JUST started to port away from Solaris this week
[12:53] <Wes> That means there may be strange build-system things going on. :(
[12:53] <Wes> I am currently testing on Solaris 10, FedoraCore 10 and Leopard
[12:55] <Wes> (what OSes are you guys running?)
[12:55] <Wes> and ashb, you're ash berlin, right?
[12:55] <MisterN> is ash berlin well known? he is.
[12:55] <MisterN> (he is ash berlin, that is)
[12:55] <MisterN> ok, fixed the bisect error
[12:56] <MisterN> /etc/mercurial/hgrc.d/hgext.rc
[12:58] <Wes> mistern: ash berlin is well known to me, we had some good conversations about a year ago; I was hoping he'd show up here. :)
[12:58] <ondras> kriskowal: so, thanks for your advice with "exports" as an argument to js function called from c++
[12:58] <ondras> it fixed all circular-related issues
[12:58] <Wes> awesome!
[12:59] <ondras> that means v8cgi is now fully compliant
[12:59] <MisterN> ondras: which javascript runtime do you use? :)
[12:59] <MisterN> oh, v8
[12:59] <ondras> afk, meeting
[12:59] <MisterN> v8 seems to be poorly documented
[12:59] <ondras> http://bespin.cz/~ondras/html/
[13:00] <ondras> doxygen from the api
[13:00] <ondras> relatively sufficient for me
[13:00] <MisterN> oh
[13:00] <MisterN> why don't google upload that?
[13:00] <MisterN> meh
[13:00] <MisterN> thx
[13:00] <ondras> because everyone can do that from actual svn version :)
[13:00] <ondras> but yes, it would be nice to have it on google page
[13:01] <MisterN> i don't usually download something before looking at the docs
[13:01] <ondras> :)
[13:01] <MisterN> _first_ i check out the docs, or browse the online source browser, then maybe i download
[13:05] <Wes> maybe they don't have enough web hosting space?
[13:05] <MisterN> Wes: i've totally lost all hg knowledge. what's this 27:34457e5bd7f6 branch?
[13:05] <MisterN> lol google not having enough web hosting space
[13:07] <MisterN> Wes: maybe you can come to #flusspferd, this discussion probably doesn't really belong here
[13:22] <ondras> re
[16:01] <agento> hi
[16:03] <agento> could someone here help out a noob with a question about rhino?
[16:04] <MisterN> just ask
[16:06] <agento> I'm planning to build a small proof-of-concept framework on top of Jack/Narwhal
[16:07] <agento> And I want to use MongoDB for persistence
[16:07] <agento> The documentation for Rhino is a little sparse
[16:07] <agento> I was wondering if there was a way to load JARs through Javascript in the initialization phase of the framework
[16:08] <agento> To access the Mongo Driver
[16:08] <agento> Or If I'd have to compile my own version of Rhino
[16:09] <ashb> agento: i dont know rhino enough to help out - someone in this channel (i forget who) works on narwhal so can probably help
[16:09] <ashb> i suggest you stay around in here
[16:10] <agento> I will, thx
[17:09] <hannesw> just got running helma ng on google appengine:
[17:09] <hannesw> http://helma-ng.appspot.com/
[17:09] <hannesw> working on a jack servlet now...
[17:11] <MisterN> hannesw: continuation fails
[17:11] <hannesw> yes, i know
[17:11] <hannesw> i think i have to activate session support, but i think it's currently broken anyway :-)
[17:20] <MisterN> hmm
[17:20] <MisterN> i think rhino has no future
[17:20] <MisterN> lack of tracing JIT :)
[17:29] <ashb> MisterN: it could be made to trace down to java byte code if it doesn't already
[17:29] <ashb> and the JVM itself is jast enough
[17:34] <MisterN> hmm
[17:35] <MisterN> but isn't it said to be slow?
[18:50] <MisterN> i like https://wiki.mozilla.org/ServerJS/Binary/B
[19:19] <tlrobinson_> hannesw: awesome!
[19:19] <hannesw> thanks :-)
[19:19] <MisterN> tlrobinson_: do you have +o because you co-founded serverjs?
[19:19] <hannesw> I love it too.
[19:23] <tlrobinson_> MisterN: dangoor started it. i was just one of the first memebers, and i set up the irc channel :)
[19:23] <MisterN> aah
[19:25] <MisterN> dangoor: which vcs do you want to use for the specs btw? and where will it be hosted? :)
[19:26] <dangoor> github is my plan
[19:27] <dangoor> i'll be setting that up first thing next week
[19:27] <MisterN> github is good, i can easily fork that then :D
[19:30] <dangoor> except all of the documents will be under Kev's Restrictive License(tm), requiring 1 MILLION DOLLARS to fork. ;)
[19:31] <dangoor> but, yeah, lots of people use and like github, so it seems like a reasonable choice
[20:13] <kriskowal> ondras: gratz on compliance! i'll go update the wiki.
[20:15] <kriskowal> ashb: the intent was that, like an array, indexing beyond bounds returns undefined, as opposed to throwing up
[20:16] <kriskowal> not that i /like/ that behavior of arrays, but that it is consistent with the rustic aesthetic
[20:17] <kriskowal> agento: i just got code working this weekend in narwhal to load jars in the initialization phase of the framework.
[20:17] <agento> Cool
[20:18] <agento> Have you pushed it yet?
[20:18] <kriskowal> it isn't in tlrobinson/master yet, but when it is, you just put your project in packages/ (or a symlink), then write a package.json file like the one in kriskowal/jack with an array of which jars you need to load
[20:18] <kriskowal> with paths relative to the file itself, package.json
[20:19] <kriskowal> {dependencies: [], js: "src", jars: ["jars/your.jar"]}
[20:19] <tlrobinson> its in tlrobinson/integration
[20:19] <kriskowal> sweet
[20:19] <agento> nice
[20:19] <kriskowal> i lost some hair making that work
[20:19] <kriskowal> hannesw fixed a bug in rhino that blocked it
[20:20] <agento> You should see how much hair I lost yesterday solving a nasty paths=problem in narwhal
[20:20] <agento> :)
[20:20] <kriskowal> oof. sorry
[20:20] <kriskowal> what was it?
[20:20] <agento> hrhr don't worry
[20:21] <kriskowal> also, the schema for package.json is prototypical at this phase.
[20:21] <agento> I uhh, have a little unorthodox layout of files in my app
[20:21] <agento> which led to require not finding its files
[20:21] <kriskowal> is your project public?
[20:22] <agento> until I discovered the LOAD_PATH variable
[20:22] <kriskowal> oh, right.
[20:22] <kriskowal> that changed, btw
[20:22] <agento> I'll try to help you guys out with documentation a little
[20:23] <kriskowal> the narwhal-rhino.js thunk now sends NARWHAL_PATH into narwhal.js directly from an environment variable that bin/narwhal-rhino sets up
[20:24] <kriskowal> gmosx has requested that application jars, in addition to package jars, be loaded into the classpath at initialization. i'm not sure what he means.
[20:24] <kriskowal> i'm guessing he has applications outside the packages
[20:29] <kriskowal> hannesw can i put helma down for passing compliance tests?
[20:30] <hannesw> kriskowal: what do you mean by "put down"?
[20:30] <kriskowal> on the wiki. i'm updating the list of implementatiosn
[20:30] <kriskowal> oh, hah. ambiguity fail
[20:30] <agento> kriskowal: I'm gonna put my project up on github
[20:30] <agento> gimme a minute
[20:31] <hannesw> my english is just not that good :-)
[20:31] <kriskowal> s/put down/write helma in the section for loaders passing the compliance tests/
[20:31] <kriskowal> mein deutsch ist schlecht
[20:31] <hannesw> oh, wow :-)
[20:32] <hannesw> well, i didn't know about any formal compliance tests?
[20:32] <kriskowal> oh!
[20:32] <agento> kriskowal: http://github.com/janv/kupo_v8/tree/master
[20:32] <hannesw> ah! great.
[20:33] <kriskowal> http://code.google.com/p/interoperablejs/source/browse/#svn/trunk/compliance
[20:33] <kriskowal> it's just a suite of unit tests for the spec, with the intent of illuminate differences of interpretation if nothing else
[20:34] <kriskowal> *intent of illuminating
[20:34] <MisterN> which spec? :D
[20:34] <kriskowal> securable modules
[20:34] <kriskowal> the fourth one
[20:35] <hannesw> ok, trying now.
[20:35] <kriskowal> hannesw there's a readme for how to set the tests up
[20:36] <kriskowal> they need sys.print, even though that's not in the spec, and program.js needs to be a top-level module for each test so that they can verify that top-level ids are distinguished from relative ids.
[20:37] <kriskowal> agento: thanks for the github link
[20:38] <hannesw> looks good so far.
[20:38] <MisterN> kriskowal: btw i like your binary proposal. but i haven't got any detailed comments
[20:38] <hannesw> kriskowal: in the compliance dir i have to run the test.js in each subdirectory?
[20:38] <kriskowal> i'm going to bet that the toString(encoding) thing is going to be dropped
[20:38] <kriskowal> no, program.js
[20:38] <agento> Not much to see there yet, just wanted to show you the layout that caused the problems for me
[20:39] <hannesw> ok, it's missing the sys property
[20:39] <MisterN> kriskowal: well yeah toString() should take no parameter.
[20:39] <kriskowal> yeah, sys can be hacked in if you don't support it
[20:40] <MisterN> how does sys.print behave?
[20:41] <MisterN> can't find that off hand
[20:41] <kriskowal> it's just a hook to lgo results
[20:41] <kriskowal> *log
[20:41] <MisterN> it takes only one parameter?
[20:41] <kriskowal> sys.print(message, "pass" | "fail" | "info")
[20:41] <MisterN> wait
[20:41] <MisterN> does that do formatting there?
[20:42] <kriskowal> it's just for the tests. the unit tests were written a couple months ago before the system proposal
[20:42] <MisterN> so there's no proposal on that yet?
[20:42] <kriskowal> no, not yet.
[20:42] <hannesw> hm, i think a global print function is actually more common. at least spidermonkey and rhino have that.
[20:42] <kriskowal> there won't be much need for sys.print apart from convenience once system.stdout is available
[20:43] <kriskowal> it's true, but global print can't be available in sandboxes
[20:43] <MisterN> i think an encodings module would be good
[20:43] <kriskowal> all io needs to go through a capability channel, albeit a free variable like sys that can be controlled by the sandboxer, or through a pre-memoized module
[20:44] <MisterN> is the stream behaviour part of the file proposal?
[20:44] <kriskowal> the system proposal suggests that system.stdin support the same API as an object returned by open(blah, "r") in the file proposal.
[20:44] <hannesw> ok, i now have defined sys.print() and it's looking much better :-)
[20:44] <kriskowal> :)
[20:45] <kriskowal> it's funny that you're making the argument for not having a "system" free variable, btw, hannes.
[20:45] <kriskowal> mark miller and i have been arguing the same point with ihab for a while now.
[20:45] <kriskowal> but ihab does have a good reason for wanting it to be a free variable instead of an injected module.
[20:46] <kriskowal> he's concerned about conflating the security name space with the pure javascript module id name space
[20:46] <MisterN> does "byte" mean "character" in file?
[20:46] <hannesw> success!
[20:46] <kriskowal> sweet!
[20:46] <kriskowal> all pass?
[20:47] <hannesw> passed all in compliance.
[20:47] <hannesw> :-)
[20:47] <kriskowal> nice
[20:47] <hannesw> yes, feels good
[20:47] <kriskowal> you might consider adding tests in the extensions section for your extensions
[20:47] <kriskowal> i've got some in there for features that chiron used to support.
[20:47] <MisterN> specifically, stream.read(n) should read n characters, not bytes.
[20:47] <hannesw> ok
[20:48] <kriskowal> MisterN the file proposal is modeled after python's. if the encoding is undefined or "binary", the resulting object operates on bytes, and Strings if there is an encoding.
[20:49] <kriskowal> hannesw if you've got a gmail account, i'll add you to the committers for the unit test project
[20:49] * kriskowal looks up your email
[20:49] <hannesw> it's hannesw
[20:49] <MisterN> by the way, streams should support ByteString / ByteArray.
[20:49] <hannesw> thanks
[20:50] <kriskowal> right. once we've nailed down the binary proposal, i think the file proposal will need to be revised to reflect those additions.
[20:50] <kriskowal> for example, i think read() should return ByteString, and readInto(buffer) should receive ByteArray
[20:51] <hannesw> kriskowal: just ran a second time to be sure. It's great to have this test suite, thanks!
[20:51] <kriskowal> write(buffer) should accept either ByteArray or ByteString
[20:51] <kriskowal> hannesw i think you've had the easiest time so far passing them :-)
[20:51] <MisterN> kriskowal: hmm
[20:52] <MisterN> kriskowal: maybe Stream should use Byte{Array,String} only if no encoding is set
[20:52] <MisterN> kriskowal: but if no encoding is set, only accept / use Byte{Array,String}
[20:52] <kriskowal> i was thinking the other way around. if there's an encoding associated with the stream, it strings can be implicitly encoded and decoded.
[20:52] <kriskowal> oh, right
[20:52] <kriskowal> same way you're thinking.
[20:53] <kriskowal> didn't see the "no" in your first line.
[20:53] <MisterN> yea
[20:53] <kriskowal> that's how python's new open() works. i keep forgetting who recommended that...
[20:54] <kriskowal> there's a link to the PEP in the "inspiration" section on the wiki
[20:55] <kriskowal> hannesw: you're now listed as an iojs committer
[20:55] <hannesw> thanks
[20:55] <hannesw> is there a wiki page with test results already?
[20:57] <kriskowal> i don't think so. i've just reorganized the "implementations" section of the specification page into those passing, those implemented, and those under development
[20:57] <hannesw> i see
[20:57] <kriskowal> https://wiki.mozilla.org/ServerJS/Modules/SecurableModules#Implementations
[21:05] <MisterN> i think we won't implement the modules stuff until (1) case sensitivity is specified (2) module versioning is specified.
[21:15] <MisterN> sent my first email to the list :)

 

 

Logs by date :