[11:00]<Wes-> So, where does the module memo belong in a web-workers environment, where the workers are implemented with OS threads? [11:00]<Wes-> (ashb, ping?) [11:01]<Wes-> My current implementation has a runtime-wide memo, which is clearly inapprorpiate - module code would be shared-everything javascript [11:02]<Wes-> My immediate thought was to tie the module memo to require, but I'm not sure that's correct, and potentially obnoxious to implement [11:02]<Wes-> What about tying the memo to the global object? Each thread must have separate globals.. [17:46]<zenon3> does anyone mind answering a couple introduction type questions about commonjs? [17:46]<deanlandolt> sure [17:46]<zenon3> I've been developing a libpurple plugin for webkit. [17:46]<zenon3> I stumbled on commonjs today. [17:47]<zenon3> I want to be able to use libpurple from javascript is my goal. However, I was going to expand out to file utilities and such. It seems like I'm stepping on familiar ground with commonjs. [17:48]<zenon3> Is there any specified way to load and use commonjs modules from any C program? [17:49]<zenon3> ...or for me to make my plugin more widely available to the commonjs community by building the module to a certain spec? [17:50]<zenon3> When looking through the site and other projects, i didn't get a clear binary module indication of how thing should be done. it seemed to all be at the JS level. [17:51]<Wes--> zenon3: I have no webkit experience, but I do similar things in spidermonkey. But, basically, you are more or less at the mercy of the javascript engine you choose to use. They are all very different at the C level. [17:55]<zenon3> ahh.. that's what I was afraid of. [17:55]<zenon3> so commonjs is at the javascript later and it's the wild west at shared lib level. [17:57]<Wes--> zenon3: Pretty much. I've been trying to standardize "how to wrote modules at the C level for spidermonkey" but nobody else is interested. :D [17:58]<zenon3> ha... yeah... I was hoping I could implement a module loading system that someone else uses and then share the module...and vice versa. [17:58]<Wes--> Hey, libpurple looks pretty neat [17:58]<Wes--> I could wrap that in GPSEE and produce a IM bot! [17:59]<zenon3> bingo! [17:59]<zenon3> GPSEE? [17:59]<zenon3> I'll have to go check that out [17:59]<Wes--> zenon3: code.google.com/p/gpsee - docs are lacking (sigh) but I'm always in #gpsee [18:00]<Wes--> I suspect getting libpurple up and running would take about a day if you're halfway experienced [18:00]<zenon3> it wasn't too hard. If I could have ditched the kids, that might have been the case. :0 [18:02]<Wes--> Oh, meant FFI bindings for it. Writing them in C as you indicate you've done would definitely be more time consuming.... at least if WebKit's C API is anything like spidermonkey's [18:02]<Wes--> (it's incredibly ... detail oriented) [18:03]<zenon3> I'm not familiar with FFI bindings. [18:03]<zenon3> Is that essentially what GPSEE was created for? [18:06]<zenon3> I see it now... I'll have to look into that. That might be the end game. [18:07]<Wes--> zenon3: GPSEE was created for a variety of reasons - but being able to interface C to JS easily and *portably* is one of my favourite features [18:08]<Wes--> i.e. if you create code with the gffi module, I promise to try very very very very very hard to make it so that it will run on any UNIX [18:08]<zenon3> I see something in the docs about augmenting spidermonkey. Does it rely on special feature of spidermonkey or a special feature of spidermonkey. [18:08]<Wes--> without code changes, or knowledge of the underlying arch by the JS developer [18:09]<Wes--> It relies on SpiderMonkey, period. [18:10]<zenon3> hmmm... It's probably non-trivial for me to try and implement similar module loading for webkit. [18:10]<Wes--> It almost certainly is, unforuntately [18:11]<zenon3> :_( [18:11]<Wes--> You might be able to steal the FFI implementation, though [18:11]<Wes--> Well, the parts that don't talk directly to the engine [18:11]<Wes--> geez, that would be pretty hard, too [18:11]<Wes--> JS interfacing at the C level is *tricky* [18:11]<zenon3> I'll have to take a look anyway. [18:12]<zenon3> Even if it's taking the spirit [18:12]<Wes--> flusspferd has gone the opposite direction from me in this regard: they are trying to do a generic C++ <> JS API .... however they only support SpiderMonkey right now [18:12]<zenon3> I was scared of the thought of having to write bridge code for other libraries. [18:12]<Wes--> zenon3: Let me know if you get stuck [18:12]<zenon3> Thanks for you help. [18:13]<Wes--> zenon3: Also, take a look at modules/net/net.js and modules/fs-base/fs-base.js to see what can be done in pure JS with my FFI stuff [18:13]<Wes--> no problem [18:14]<Wes--> And I apoligize in advance for the lack of comments in net.js, it's a work in progress. :) [18:14]<zenon3> haha... I'm afraid to show anyone my code yet. I got things working and now I'm looking to standards so I can start refactoring. [18:19]<zenon3> gotta run.. Thanks again for your help Wes. I think I have some reading to do. [21:05]<kriskowal> Dantman? [21:07]<kriskowal> the wiki appears to be down.