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

2010-03-08:

[0:17] <Dantman> lol, nio buffers provide an interesting alternative to toString(charset, start, stop)
[0:20] * Dantman wishes for a inbuilt Error.createConstructor(name);
[0:22] <Dantman> *twitch*, Waitasecond... They standardized something nice like Object.create, but went for something ugly like Array.isArray... Bleh, they could almost have had another good pattern.
[0:23] <Dantman> Array.is, String.is, Function.is, RegExp.is, Date.is, etc...
[0:25] * Dantman almost wants to switch the isString, isFunction, etc... in Wrench.js to that pattern.
[0:31] <Dantman> typeof, instanceof, isNaN..... Array.isArray? gahhh
[0:35] * Dantman debates between endian set on Buffer, or endian arguments.
[0:42] <Dantman> Can't decide if I should retain mark() and reset() when coming up with an api.
[0:55] * Dantman needs to come up with another word to describe the plain object providing the raw read/write api that gets handed to a Stream, or else he's going to end up abusing either the term interface, spec, or schema
[1:08] <Dantman> Now I'm teetering between abusing template or generic
[1:12] <Dantman> Ahah, I'll abuse "driver"
[1:18] <Wes-> dantman: spidermonkey will throw an uncatchable OOM
[1:18] <Wes-> Dantman: this means that I can report it to the embedding environment, but not JS programs
[1:19] <Dantman> Any way to know you are about to oom ahead of time and avoid it?
[1:50] <Dantman> Ahhh, I don't think current promises fit into what I'm thinking of for piping.
[1:51] <Wes-> Dantman: There is no way to know that the next operation will OOM you, but you could easily expose an interface to give you a clue that it was coming
[1:52] <Wes-> Dantman: hell, you could probably trigger an asynchronous event to let you know
[1:52] <Wes-> in this case by asynchronous I mean pre-emptive
[1:54] <Dantman> Mhmm, I understood
[1:55] <Dantman> Heh, guess what I'm really thinking of instead of promises is an inter thread api in a way.
[5:48] <Dantman> Mmm, Java's java.util.concurrent.ThreadPoolExecutor looks interesting.
[5:48] <Dantman> Not applicable to workers in the way I want, but still interesting.
[8:01] <Dantman> Heh... "Hmmm... I need something like promises that apply to inter-thread .wait and .then... I know, I'll call them 'contracts'!" *snicker*
[8:17] <kriskowal> Dantman http://en.wikipedia.org/wiki/Design_by_contract
[8:24] <Dantman> Heh... should I call them Futures instead?
[8:25] <Dantman> Actually, maybe I'll just call it a ConcurrentPromise
[8:31] * Dantman needs to get a headphone jack splitter so he doesn't need to reach over his monitor to switch his surround sound system from his computer to his iPod's dock.
[8:33] <Dantman> *sigh* A whole drawer full of cords, wires, and electronic accessories of random types, and I never have what I need...
[8:34] <Dantman> Heck, I think I have a foot of sample fibre optic cable...
[8:47] <kriskowal> Dantman "futures" is also a well-established term with a subtle distinction http://en.wikipedia.org/wiki/Futures_and_promises
[15:23] <Wes-> Dantman|Sleep: invest in a soldering iron, you'll never want for a cord again ;)
[15:24] <Dantman|Sleep> Heh
[17:10] <Dantman> Wes-, ashb; Got any ideas for better method names than java.nio's .clear() .flip() .rewind() .compact()?
[17:10] <ashb> Dantman: the entire api seems needless from what i can tell
[17:15] <Dantman> Well if you don't have a mutable length buffer this is a good second.
[17:40] * Dantman needs more binary/file/stream use case examples.
[17:48] <Dantman> Heh, prepareForWrite feels a little long.
[23:06] <kriskowal> ashb what was that solution you recommended for managing changes in a subrepository?
[23:06] <kriskowal> as an alternative to git submodules?

 

 

Logs by date :