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

2010-03-14:

[4:50] <sh1mmer> anyone have any thoughts about good places to run node in the cloud?
[4:50] <sh1mmer> I heard a rumour about joyent and some kind of out of the box node support
[5:19] <Dantman> ^_^ Yay. the dns
[6:53] <Dantman> Anyone up right now?
[6:53] <kal> Dantman well.. kinda :P
[6:54] <Dantman> kal, Care to create a dummy http://wiki.commonjs.org/wiki/Website:Index/test for me?
[6:54] <Dantman> My edits are autoreviewed.
[6:55] <kal> donee
[6:55] <kal> I think :S
[6:56] <Dantman> ok. i'll have to fix the website's script
[6:57] <kal> it's supposed to not allow for direct changes or?
[6:57] <Dantman> See http://commonjs.org/test/
[6:58] <Dantman> Try making an edit to http://wiki.commonjs.org/wiki/Website:Index and seeing how nothing happens to http://commonjs.org/
[6:58] <Dantman> Right now changes to a page that was once reviewed will not show up till those changes have been reviewed.
[6:58] <Dantman> However if a page was never reviewed (you just created it) the latest revision will show up on the wiki.
[6:59] <Dantman> So you can't spam an existing page, but you can create any page you want and make it show up on the wiki without review.
[6:59] <kal> Ah I see :O
[6:59] <Dantman> unreviewed pages should probably be 404s until reviewed.
[7:00] <kal> seems logical
[7:02] <Dantman> ^_^ http://commonjs.org/test/ done
[7:03] <Dantman> And the draft works right as well http://draft.commonjs.org/test/
[7:03] <kal> Dantman: nice! :)
[7:05] <Dantman> I wonder if I should make a footer note that I manage the website and host it on a redwerks server.
[7:07] <kal> well it's quite a lot of text to put in a footer so maybe link in the footer to something like a "about the site" and there's a lot of space for info :)
[7:08] <Dantman> Meh, we already have "Copyright © 2009 - Kevin Dangoor and many CommonJS contributors. MIT license."
[7:08] <Dantman> A little "Managed by Daniel Friesen, Hosted on servers paid for by Redwerks"
[7:08] <Dantman> is nothing
[7:09] <kal> well how'd you up it there then, on the same line or on another? :)
[7:09] <Dantman> Another
[7:09] <Dantman> Not that we're short horizontal space
[7:14] <Dantman> ^_^ Actually there's enough room to fit both lines on a single line without going past the content area width.
[7:15] <kal> okeey yea that kinda works, and I do get why'd you want it there
[7:21] <Dantman> When we create an auth system for Kommonwealth maybe I'll create a auth extension to MediaWiki.
[7:55] <Dantman> kal, Mind modifying http://wiki.commonjs.org/wiki/Website:Index too?
[8:09] <kal> Dantman: sorry was away, done now :)
[8:13] <Dantman> Heh
[8:19] <kriskowal> Dantman thanks for setting up the wiki/website. What's the new relationship between the commonjs github account and the new wiki-based CMS?
[8:19] <Dantman> github account?
[8:50] <Dantman> kriskowal,
[8:50] <Dantman> Agh, damn laptop
[8:50] <kriskowal> ,Dantman
[8:50] <Dantman> kriskowal, No relation anymore really... that's old content...
[8:51] <Dantman> The new commonjs.org site is nothing but a simple .htaccess that redirects everything to index.php, a all exclusive robots-draft.txt file, and a index.php
[8:52] <kriskowal> ok. what about the non-wiki stuff in the commonjs github. is it no longer hosted?
[8:52] <kriskowal> perhaps we need a subdomain to take advantage of gh-pages for that?
[8:52] <Dantman> http://gist.github.com/331871
[8:52] <Dantman> Non wiki?
[8:53] <kriskowal> unit tests
[8:53] <kriskowal> that kind of thing
[8:53] <kriskowal> it's probably fine just to reference the github page. thanks
[8:53] <Dantman> Well, the only thing I changed was the website... if there is non-website stuff inside the commonjs repo that's still relevant.
[8:54] <Dantman> If there was something somehow available to view on the old website that no longer works on the new one please point it out.
[8:57] <Dantman> I could also make unit tests viewable somewhere.
[9:21] <kriskowal> hannesw here's my preliminary cut of the Narwhal libraries decoupled from Narwhal proper and provided as a package http://github.com/kriskowal/narwhal-lib/
[9:22] <hannesw> kriskowal very cool! thanks!
[9:22] <kriskowal> ashb Wes-- ondras tlrobinson ^
[9:22] <kriskowal> i'm using git-subtree to keep it in sync without having to use submodules
[9:22] <kriskowal> i'm optimistic
[9:22] <hannesw> ah, didn't know about subtree
[9:22] <kriskowal> let me know if you want more or less in there
[9:23] <kriskowal> it does not presently include tusk
[9:23] <hannesw> now it may be we (ringo) won't need this after all
[9:23] <kriskowal> with subtree?
[9:23] <hannesw> because narwhal proper installs properly as a package
[9:23] <kriskowal> ah, yeah
[9:24] <hannesw> well i guess the default catalog entry for narwhal could be changed to narwhal-lib
[9:24] <hannesw> but we definitly want tusk :)
[9:24] <hannesw> http://ringojs.org/wiki/Tusk/
[9:24] <ondras> hmm
[9:24] <ondras> does not look bad
[9:24] <ondras> (narwhal modules separated)
[9:25] <ondras> the question is: what is the nature of its relation to narwhal now?
[9:25] <kriskowal> tom and i have made some headway on making tusk usable on other engines
[9:25] <kriskowal> ondras: flexible
[9:25] <ondras> hmmh
[9:25] <ondras> s/narwhal-lib/commonjs-lib/ ?
[9:25] <ondras> :)
[9:26] <kriskowal> to do so would require approval of everyone on commonjs, i think
[9:26] <ondras> my aim is not to bring in "commonjs", but rather remove "narwhal"
[9:27] <kriskowal> it would also put commonjs in the business of maintaining an implementation in addition to specifications. it might be good to keep them separate
[9:27] <ondras> because being impl-agnostic is the very nature of these modules
[9:27] <hannesw> kriskowal: i got tusk running just fine on my ringojs branch the other day
[9:27] <kriskowal> that's sweet, hannesw
[9:27] <hannesw> yep, it's great
[9:27] <kriskowal> tom got it running on narwhal-jsc the other day too
[9:28] <kriskowal> i'm a sync http module away from getting it to work on narwhal-node
[9:28] <hannesw> very cool
[9:28] <kriskowal> which naturally begs whether i ought to just make it work async
[9:28] <ondras> hm
[9:28] <ondras> exports.hash = function (s, _characterSize) {
[9:28] <ondras> pity we cannot use binary yet
[9:28] <kriskowal> it would be nice.
[9:29] <kriskowal> a lot of these modules have been simply ported from browser implementations
[9:29] <ondras> I have done the same in v8cgi :/
[9:29] <kriskowal> ondras, also, i have a branch of narwhal with your optparse. i'm not sure what to do about it.
[9:29] <ondras> never the less, it is indeed a very good idea to have at least one repository of purejs modules
[9:30] <kriskowal> args.js is pretty nice
[9:30] <ondras> kriskowal: if you think it is worty, move it to this library...
[9:30] <kriskowal> i'm not sure it is
[9:31] <ondras> args.js is not thoroughly documented, can I see some apidocs/usage somewhere?
[9:31] <ondras> it looks rather complex to me
[9:31] <kriskowal> it's jquery-like
[9:32] <kriskowal> http://github.com/280north/narwhal/blob/master/lib/narwhal/tusk.js
[9:32] * ondras is not a big fan of jquery syntax
[9:32] <kriskowal> http://github.com/280north/narwhal/blob/master/lib/narwhal.js
[9:32] <kriskowal> i tend to agree, but this is a nice fit
[9:33] <hannesw> is that narwhal's args.js?
[9:33] <kriskowal> yeah
[9:34] <hannesw> we have a simpler one: http://ringojs.org/api/ringo/args
[9:34] <ondras> hannesw: your api seems very close to v8cgi's one
[9:34] <hannesw> it's much more limited, but quite nice to use
[9:34] <kriskowal> if you s/addOption/option/, it's a strict subset, i think
[9:35] <hannesw> e.g. http://github.com/ringo/ringojs/blob/master/modules/ringo/webapp/daemon.js
[9:35] <kriskowal> almost
[9:36] * Dantman needs to come up with better names than flip and compact.
[9:37] <kriskowal> Dantman yeah, probably. what are the corresponding behaviors?
[9:37] <Dantman> For a ByteBuffer with inbuilt position and limit support.
[9:39] <Dantman> flip sets the limit to the current position, and the position to 0 preparing the buffer for get operations (ie: Writing data out from the buffer).
[9:39] <kriskowal> hannesw, it would be nice if we could align our args modules so that one can switch more easily between the two
[9:39] <Dantman> ie: You read data into a buffer, then call .flip() and it's ready for you to read that data out.
[9:39] <kriskowal> and i don't mind name-spacing our args module; we can move things into a narwhal subdir no-problem
[9:40] <kriskowal> we'll have to deprecate and migrate, of course
[9:40] <hannesw> kriskowal: not sure, I'd like to keep our args as simple as it is
[9:40] <kriskowal> i agree, just names
[9:40] <hannesw> Dantman: not entirely convinced about flip()/compact()
[9:41] <Dantman> compact copies any data in between position and limit to the start of the buffer, places the position at the end of the new location of the data, and sets the limit to the capacity of the buffer.
[9:41] <hannesw> basically you let the buffer manage two index variables which you otherwise manage yourself: position and end
[9:41] <Dantman> In other words preparing the buffer to read new data... without overwriting data that has not yet been read from the buffer.
[9:42] <ondras> kriskowal: how does args.js handle options with optional values, default values and numeric/repeatable options like "verbosity" ?
[9:42] <ondras> also, exports.Parser.prototype.Parser = exports.Parser; is somewhat confusing
[9:42] * ondras wants api docs to understand it :/
[9:43] <kriskowal> ondras, yeah, it's on the todo list
[9:43] <Dantman> hannesw, ^_^ So which code do you want to use? http://pastie.org/866053
[9:44] <kriskowal> ondras, we follow python's lead about optional values on options?they're not allowed because they introduce non-determinism. default values are provided by .def(). numeric-repeatables are managed by .inc() and .dec()
[9:45] <kriskowal> .inc() and .dec() are examples of methods that are trivially implemented on top of the basic .action() and .validate() methods.
[9:46] <ondras> I see
[9:46] <kriskowal> we also support all of the gnu conventions. -fbar --foo=bar --foo bar
[9:46] <ondras> from my point of view, args.js does about a million advanced things which I had no need for (so far)
[9:47] <ondras> it is pretty high level
[9:47] <ondras> including type validation
[9:47] <ondras> color output
[9:47] <ondras> etc
[9:47] <kriskowal> a strict subset of it is pretty simple.
[9:48] <kriskowal> i like hannes's approach.
[9:48] <kriskowal> i think it would be nice if someone can start with ringo/args and upgrade to narwhal/args if they want to buy in
[9:49] <kriskowal> i think it's pretty close
[9:49] <kriskowal> ringo/args's .addOption is essentially the same as narwhal's .option
[9:49] <ashb> Dantman: transclude means you can get content on the website without needing to approve it :)
[9:49] <ashb> http://commonjs.org/specs/modules/1.0/
[9:49] <ashb> right at the end :)
[9:50] <Dantman> I know...
[9:50] <ondras> kriskowal: ringo's addOption seems to be very close to my .add(), on the first sight
[9:50] <kriskowal> hannes's .help is different, i think
[9:50] <Dantman> Flagged revs can handle that, if I enabled it inside the other namespace.
[9:50] <ashb> speaking of arg validation, flusspferd;s is:
[9:50] <kriskowal> maybe we can hash out some common ground on commonjs
[9:51] <Dantman> But flagging everything doesn't feel too necessary.
[9:51] <ondras> kriskowal: also, I belive my impl also supports all gnu conventions, including -abcdef for -a -b -c -d -e -f
[9:51] <ashb> not loading for some reason...
[9:51] <kriskowal> ondras, yeah, we do too
[9:51] <ashb> wtf its just static html. whats going on here
[9:51] <kriskowal> -fbar is only equiv to -f bar if the f option takes an argument
[9:52] <ondras> kriskowal: however, -v is an example of optional argument
[9:52] <ondras> -vvv or -v -v -v or -v 3
[9:52] <ondras> how do you do this?
[9:52] <kriskowal> we only support one or the other
[9:52] <ondras> okay
[9:52] <kriskowal> .inc() does -vvv and -v -v -v, and .set() supports -v 3 and -v3
[9:52] * ondras thought this was also some kind of convention
[9:53] <ondras> but my unix experience is not large
[9:53] <ashb> http://flusspferd.org/docs/js/flusspferd%20core/getopt.html
[9:53] <ashb> there we go
[9:53] <ondras> :)))
[9:53] <ondras> more impls!
[9:54] <ondras> ashb: why don't you use the class approach?
[9:54] <ashb> 'class approach'
[9:54] <ashb> ?
[9:54] <ondras> bad naming, I now
[9:55] <ondras> var x = new X(); x.stuff()
[9:55] <kriskowal> python has modules for both approaches
[9:55] <ondras> x.showHelp(), x.parse(), ...
[9:55] <ashb> didn't see the need
[9:55] <kriskowal> people coming from shell expect ashb's style
[9:55] <ashb> there's not exactly a lot of internal state toe manage
[9:55] <ondras> instead of x_showHelp(data), x_parse(data), ...
[9:55] <ashb> its pretty much a direct mirror of gnu's getopt, yeah
[9:56] * ondras believes that internal state is not the only reason to use "new"
[9:56] <kriskowal> i named args.js to avoid confusion with getopt
[9:56] <kriskowal> if there's a getopt module, i think it should look like ashb's
[9:56] <ashb> ondras: sure, but also if you can do it all in one call most of the time///
[9:56] <Dantman> ashb, Try it again...
[9:57] <ondras> ashb: yeah
[9:57] <kriskowal> it make sense for args.js's Parser object to exist since it's possible to create subtypes that support specific styles of option decorators
[9:58] <kriskowal> but apart from that, it's just sugar
[9:58] <kriskowal> ashb, i'd adopt your getopt.js module wholesale if it conformed to crockford style
[9:58] <ondras> it is a pity that the ultimate goal of a standardization process is to throw away N-1 implementations, each being Y lines of nice debugged functional code...
[9:59] <ashb> kriskowal: yeah blame those C++ coders ;)
[9:59] <ashb> they wrote it
[9:59] <ashb> kriskowal: also its written in C++ since it what we use for parsing args for the main binary
[9:59] <ondras> "crockford style", what is that? no ==, no continue, no break, ... ?
[9:59] <ashb> camelCase
[10:00] <kriskowal> http://javascript.crockford.com/style1.html
[10:00] <ashb> kriskowal: you're fine with the v:[undefined,undefined] result style?
[10:00] <kriskowal> i'm not sure what you mean
[10:01] <ashb> -vv input produces output of v:[undefined,undefined]
[10:01] <ashb> which still feels a little odd to me
[10:01] <ashb> but its kinda correct
[10:01] <kriskowal> in what?
[10:01] <ashb> our getopt
[10:01] <kriskowal> oh, in getopt
[10:01] <kriskowal> seems fine to me.
[10:02] <kriskowal> when you look at the "v" option, you're looking for .length anyway
[10:02] <ashb> hmmm someone do me a favour: try sshing to 178.63.242.208
[10:02] <ashb> tell me if you get a login or a timeout
[10:02] <kriskowal> not it
[10:02] <ondras> login
[10:02] <kriskowal> http://wiki.commonjs.org/index.php?title=Coding_Standards&action=history
[10:03] <kriskowal> there was virtually no argument about following crock's lead
[10:03] <ashb> ondras: thanks
[10:03] <kriskowal> but that was back in february last year
[10:03] <ashb> kriskowal: yeah i mostly do camelCase for public and under_score for 'private'
[10:03] <kriskowal> maybe a quarter of our active discussion participants were not with us at the time
[10:04] <ashb> i.e. methods that you can call if you want, but dont complain when something changes
[10:04] * ondras has no problems here, but I am certain some people do not like "The { (left curly brace) should be at the end of the line that begins the compound statement."
[10:04] <ondras> etc etc
[10:04] <ondras> hm
[10:04] <ondras> Avoid use of the continue statement. It tends to obscure the control flow of the function.
[10:04] * ondras is not okay with this
[10:04] <ashb> yeah - tbh crockford is as wrong as he is right
[10:04] <kriskowal> avoid isn't the same as forbid
[10:04] <ondras> ok
[10:04] <kriskowal> a lot of this is non-normative
[10:05] <ashb> position of '{' doesn't matter so long as its consistent in a module/project
[10:05] <ondras> afk, going to cook lunch
[10:05] <kriskowal> afk, going to sleep :P
[10:05] <ondras> :))
[10:05] <ondras> gn
[10:09] <Dantman> ashb, going to re-vandalize the modules spec?
[10:10] <ashb> oh sure
[10:11] <ashb> edited
[10:11] <ashb> still shows up
[10:11] <Dantman> Oh well
[10:12] <ashb> you can't include a specific revision?
[10:12] <Dantman> If it ends up as a real issue I can enable flagged revs through the site...
[10:13] <Dantman> ashb, FlaggedRevs has built in handling so that included pages are stuck til reviewed, but I guess it only works when both pages use flagged revs... I only have flagged revs enabled in the Website namespace.
[10:13] <ashb> ah
[10:17] * Dantman still needs to come up with a replacement for flip and compact
[10:32] <Dantman> Hmm... does .mark() and .retrace() sound like a reasonable pair... ie: You .mark() your current location, do stuff that pushes the .position forward, then .retrace() to reset the .position to where it was when you called mark()?
[10:32] <ashb> i'm mainly not sure its a sane API
[10:38] <zumbrunn> Dantman: is the email confirmation for the wiki accounts supposed to work?
[10:38] <zumbrunn> I tried when you set up the wiki originally and I registered and I retried yesterday
[10:39] <zumbrunn> and I don't get an email I could confirm
[10:40] <ashb> Dantman: fwiw those do sound like better names. mark at least does anyway
[10:50] <Dantman> Different part of the api...
[10:50] <Dantman> That was a replacement for Java's mark/reset pair...
[10:51] <Dantman> reset sounds too heavy for something that merely returns the position index to a previous location.
[10:51] <Dantman> reset sounds like a better name for clear... resetting position, limit, and mark to their default locations.
[10:53] <ashb> but mainly - what's your thought on why those sohuld be members of the buffer?
[10:55] <Dantman> Heh, in that case I just don't feel like using a backend object that supports them, and discarding the functionality...
[11:01] <Dantman> ^_^ Heh, and if your impl doesn't have a backend with built in mark and you don't feel like coding it in C..... Buffer.prototype.mark = function() { this._mark = this.position; return this; }; Buffer.prototype.retrace = function() { if ( this._mark === undefined ) throw "Invalid mark"; this.position = this._mark; return this; }
[11:02] <Dantman> Actually, besides compact; the equivs of Java's clear, rewind, and flip can all be trivial prototypes that don't even need to be written outside of JS.
[11:03] <ashb> compact does?
[11:03] <ashb> I often find its better to think of APIs driven form the use case, not just existing APIs
[11:04] <ashb> existing APIs oftne come with baggage in terms of naming/expected behaviour that might not be right for us
[11:04] <Dantman> "compact copies any data in between position and limit to the start of the buffer, places the position at the end of the new location of the data, and sets the limit to the capacity of the buffer. In other words preparing the buffer to read new data... without overwriting data that has not yet been read from the buffer."
[11:04] <Dantman> mentioned it earlier
[11:04] <ashb> that seems like a really expensive operation
[11:05] <ashb> its a much 'smarter' buffer than most people are talking about
[11:05] <Dantman> Keep calling .write till you've written everything, or prepare your buffer for read to make use of the space that is left inside of your buffer; Pick your poison...

 

 

Logs by date :