[15:12]<sid3k> Hi all, new implementation form in the wiki doesn't work... [15:19]<dmachi> sid3k: i think they are migrating the wiki or making changes to it, there has been a lot of discussion over the past couple of days on the mailing list about this. [15:21]<sid3k> dmachi: arright [15:21]<dmachi> (I beleive someone is moving it to github to be a wikl here, but i'm not 100% sure) [15:22]<sid3k> hmm, github wiki would be great [15:23]<dmachi> yeah, i think thats what they are doing...but i don't think they've gotten much past someone taking on the task (this was just yesterday this was all discussed) [15:40]<deanlandolt> sid3k: yeah, sounds like irakli is getting the ball rolling on moving to github [15:51]<Wes-> Personally, I would rather we spent time on advocacy and developing content for commonjs.org, jshq.org, etc than porting the wiki [15:51]<Wes-> But, at least the port should(?) mean the end of on-going maintenance [15:52]<Wes-> You know what would be cool? [15:52]<Wes-> A CommonJS Blog [15:52]<Wes-> where the key implementors and big mouths in the CommonJS mailing list contribute posts [15:52]<Wes-> say, we assign each week to a different guy, to post "something neat" that can be done with CommonJS [15:53]<Wes-> Or even stuff that is slightly pre-common-js [15:55]<Wes-> Like, dean, introducing your common-binary-stuff module would be sweet [16:02]<zumbrunn> Wes-: I agree that moving to github is just a nice-to-have taks, but the only reason it hasn't happened in the past was because no one stepped forward to do it, right? [16:02]<zumbrunn> it's not that there was actual disagreement, questioning whether it would be a good move [16:03]<zumbrunn> and on the other hand I think we settled that staying on a vps would have been fine as well [16:03]<zumbrunn> and that the financials are a non-issue [16:03]<zumbrunn> it's just that someone needs to do it, whatever we do [16:03]<zumbrunn> so, if the github thing is happening, that's great [16:04]<Wes-> zumbrunn: Right - both you and I are able to fund this kind of stuff (I secured approval this morning) - the hardest thing is finding the man power to do the work, and manage the results on a on-going basis [16:04]<Wes-> I'm personally ambivalent on github - it's nice that there is no maintenance, but I personally prefer to control the platform [16:05]<zumbrunn> the nice thing about github is that we could later just use it as a backend, if we wanted to [16:05]<zumbrunn> and build a commonjs implemented web app as frontend [16:07]<Wes-> zumbrunn: Yeah - being able to access the wiki as an SVN repo (it must be possible?) is a good thing [16:07]<Wes-> er, GIT repo, lol [16:07]<zumbrunn> hehe [19:24]<deanlandolt> Wes- that's a good idea...i'll start writing something up...but first i have to solve the chicken/egg problem of how to actually /test/ binary without a binary constructor :-/ [19:24]<Wes> deanlandolt: what does your binary constructor need? [19:25]<deanlandolt> well, i'm just spoofing whatever platform native binary that's available [19:25]<Wes> deanlandolt: So use binary from GPSEE to test [19:25]<deanlandolt> i guess just a string or other binary...fixed length buffers take a length [19:26]<deanlandolt> yeah, i can use any of hte binary natives, but i'm trying to write tests regardless of binary...turns out you need to construct binary for that and we don't have a constructor [19:27]<deanlandolt> i guess that can just be a library feature though, no need for it to be a constructor [19:28]<Wes> deanlandolt: idea 2 - typed arrays for webgl - you can test in most modern browsers [19:28]<Wes> Although I'd like to convince you to download gpsee. ;) [19:28]<deanlandolt> yeah, that's another host-supplied binary we can patch [19:29]<deanlandolt> heh...i'll do that now :) [19:29]<Wes> you probably want to pull from hg, the tarball has a couple of install-related bugs (ld_library_path stupidity) [19:30]<deanlandolt> k