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

2009-12-10:

[0:13] <deanlandolt> ashb: i just sent a concrete promise example to the list that may answer some questiosn
[0:13] <ashb> k
[0:14] <ashb> will read it tomorrow
[0:14] <ashb> trying to work out how this timer is going out of scope
[0:14] <deanlandolt> ouch...enjoy :/
[0:14] <ashb> yeah
[0:14] <ashb> its a pain
[0:15] <ashb> hate C++ at times
[0:16] <ashb> okay now its staying in scope, but its just not firing >_<
[3:29] <tlrobinson> what are people's thoughts on system.args being immutable?
[3:30] <tlrobinson> i've found cases where it would be nice to know they're the *actual* arguments
[3:30] <tlrobinson> but also cases where it's nice to be able to modify them (like in jackup)
[6:39] <ondras> tlrobinson: /me votes for mutable
[6:39] <ondras> they are mutable in c
[6:39] <ondras> and I don't actually see a case where mutability would be a source of any issue
[11:51] <ondras> hmm
[11:51] <ondras> Object.getPrototypeof() returns the prototype of the given object
[11:51] <ondras> vs. getPrototypeOf ?
[13:13] <ashb> ondras: ?
[13:14] <ondras> ashb: yessir!
[13:15] <ashb> ondras: what was your question about getPrototypeOf?
[13:16] <ashb> deanlandolt: your example doesn't show something working with sync and async
[13:16] <ondras> ashb: is there "of" or "Of" ?
[13:17] <ashb> oh
[13:17] <ondras> I came across some article which had "getPrototypeof" in it
[13:17] <ashb> Of
[13:17] <ondras> okay
[13:17] * ondras is glad :)
[13:18] <ashb> deanlandolt: also onFlush is badly named - it might not be flushing, just writing (i'm not sure if the conceptual difference there matters)
[14:52] <deanlandolt> ashb: if you look at the library it /turns/ a sync response into a promise at both levels, so it will work with either response type
[14:52] <ashb> deanlandolt: yeah i saw that afterwards
[14:53] <deanlandolt> also, onFlush may not be the best name but that's pretty much what each progress event would signify: here's another forEachable to flush
[14:53] <deanlandolt> writes would just be collected up, but when the progress event is called with a forEachable, it works its way back to the server to be flushed
[14:54] <ashb> not sure. flush is a different operation to just a print
[14:55] <deanlandolt> well sure, but you're printing as you build the forEach
[14:55] <deanlandolt> you return that object when you want it to flush
[14:55] <deanlandolt> and obviously we'd have a library that wrapped that...so you'd have some kind of response helper that lets you .write (or .print) to it...and .flush it...
[14:56] <deanlandolt> the act of flushing it is what calls the progress event on the promise...i can give an example
[14:56] <ashb> why isn't it the act of printing?
[14:56] <ashb> on print and on flush should be different events
[14:56] <deanlandolt> perhaps -- it just makes things awkward
[14:56] <ashb> for instance doing long poll you might want to print 20bytes then flush
[14:56] <ashb> but if its not they you just print and let other things deal with that
[14:57] <deanlandolt> sure...but middleware wouldn't get ahold of your prints -- just the final flushed forEachable
[14:57] <ashb> why can't it get hold of prints?
[14:57] <deanlandolt> so you can print all you want and when you're ready to push it through the chain that's what flush is
[14:57] <ashb> not sure i like that idea
[14:57] <deanlandolt> well, in this paradigm it can't...i guess what i'm wondering is why it needs to see each print? it can't really do much until you're ready to flush anyway, right
[14:57] <deanlandolt> ?
[14:58] <ashb> dunno. i'm coming at it from the stream filter idea i guess
[14:59] <deanlandolt> understood...but what would middleware do to the individual writes?
[14:59] <ashb> what ever it wants?
[14:59] <ashb> process it, buffer it (for say not enoguh data to gzip well, etc)
[15:00] <deanlandolt> sure, but nothing's really happening until a flush anyway, right?
[15:00] <deanlandolt> nothing will hit the client at least
[15:00] <ashb> no it might
[15:00] <ashb> flushes are almost never explicit
[15:01] <deanlandolt> okay...i can see that side of things
[15:01] <deanlandolt> so onFlush isn't /really/ the event
[15:01] <deanlandolt> better name? what does node call it?
[15:02] <ashb> it doesn't have middleware at all
[15:02] <deanlandolt> i know...but it does have a write chunk event
[15:02] <ashb> print i think
[15:02] <ashb> tho thinking about it
[15:02] <deanlandolt> that's effectively what returning a forEachable as a progressEvent does
[15:02] <ashb> there is no way to flush a socket
[15:03] <ashb> unless toggling TCP_NODEALY does it
[15:08] <ashb> hmmmmm whats keeping this alive i wonder
[15:09] <deanlandolt> keeping what alive?
[15:09] <ashb> my event_loop
[15:09] <deanlandolt> magic?
[15:09] <ashb> yeah
[15:09] <ashb> clearly
[15:21] <ashb> hmmm thats a bit annoying.
[15:21] <ashb> when run() returns from no work left, you have to call reset() befor it can start again
[15:21] <ashb> but if you call reset to early odd things seem to happen
[15:22] <deanlandolt> ashb: what's this?
[15:22] <ashb> boost::asio::io_service
[15:22] <ashb> i.e. the event loop
[15:23] <deanlandolt> oh...yeah...well, can't help ya there :)
[15:24] <ashb> go on
[16:13] <ashb> speaking of timers: http://pastie.org/private/gvmxftcdcwocwbufnukvnw
[17:21] <rektide> w/r/t to SecurableModules, are modules loaded in sandboxes?
[17:22] <rektide> are require/exports just a common interface for discussion, or do they imply containerization as well?
[17:25] <ashb> rektide: they might be, but aren't required to me
[17:26] <ashb> rektide: what do you mean by 'imply containerization'?
[17:28] <rektide> do modules share a common namespace
[17:28] <rektide> or are they each in their own namespace
[17:29] <ashb> namespace of scope?
[17:29] <ashb> i.e. if a module does var a = 1; cna other module see that var you mean?
[17:33] <rektide> yes, that is my question
[17:33] <ashb> it shouldn't, but its implementation dependant
[17:33] <ashb> i.e. not required, just recomemneded
[17:34] <ashb> i think all of hte implementations i know of do hto
[17:34] <rektide> ashb: what about node.js?
[17:34] <rektide> can we transit over to node.js?
[17:34] <ashb> ah not sure about node.js, but node's commonJS support is minimal
[18:49] <Wes-> IIUC node implements only "require"
[18:49] <Wes-> and no commonjs modules
[18:49] <Wes-> Not sure how conformant his impl is
[20:22] <ashb> \o/ timers work
[20:22] <ashb> http://github.com/ashb/Zest/blob/timers/test/timers.t.js
[21:15] <Wes-> ashb: what's your implementation back end?
[21:16] <Wes-> ashb: I have been considering putting something together which is an event loop
[21:16] <Wes-> ashb: Don't know if it should be in #! /usr/bin/env commonjs or in another gpsee-enabled app
[21:17] <Wes-> ashb: doing it in an outside app would work well for you, too, as you could then make the app responsible for the event loop, preserving flusspferd "under and game's event loop" semantics otherwise
[21:37] <ashb> Wes-: its from Zest
[21:38] <ashb> so boost::asio
[21:38] <Wes-> what does boost::asio do?
[21:39] <ashb> asio = AsyncIO
[21:39] <ashb> so async sockets, timers
[21:39] <Wes-> any idea how it works?
[21:40] <ashb> select/epoll/kqueue etc
[21:42] <Wes-> yeah, but do you need to run your script as a boost asio event? or how does it know to trigger the timeout via js?
[22:05] <ashb> oh, require('zest').asio.run();
[22:06] <ashb> or start a zest http server and it will do that for you

 

 

Logs by date :