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

2010-02-19:

[0:31] <ashb> so initially i have no problems with the sync/async-ness
[0:37] <ashb> so initially i have no problems with the sync/async-ness
[0:37] <ashb> kriskowal_: ^^
[0:37] <kriskowal_> yeah, i got it
[0:37] <ashb> tho i'm not sure what is the bast naming
[0:37] <kriskowal_> so, sfs-base?
[0:37] <ashb> aos, sos feels a bit funny.
[0:37] <kriskowal_> sure does
[0:37] <kriskowal_> os, sos isn't so bad
[0:37] <kriskowal_> nor os, aos
[0:38] <kriskowal_> or os, os-async
[0:38] <kriskowal_> or os, os-sync
[0:38] <MisterN> os sos??
[0:38] <ashb> yeah i think one of the of {,[as}<module> or similar sits better with me
[0:38] <kriskowal_> it's a difficult issue
[0:38] <ashb> something like that
[0:38] <ashb> i dont like both being named
[0:38] <ashb> /tagged
[0:38] <kriskowal_> s-os, os
[0:39] <kriskowal_> as long as that's the case, i think the node people are going to cry louder and more belligerently than those of us who aren't anti-sync
[0:40] <kriskowal_> os, sos seems more likely to converge than os, aos
[0:40] <kriskowal> or os, os-sync over os, os-async
[0:40] <ashb> the os module in this case is what exactly?
[0:40] <ashb> sleep, system etc?
[0:40] <ashb> (not that it matters)
[0:40] <kriskowal> yeh, basically
[0:41] <kriskowal> let's use fs as the example. "os" is only interesting because it illustrates the oddity of "sos" if the idea is taken to its natural conclusion
[0:41] <MisterN> kriskowal: maybe using abbrevations is folly anyways.
[0:42] <kriskowal> it *would* be nice to have a promise-returning variant of narwhal's "os" someday though; it has exit, system, popen and the like
[0:42] <kriskowal> might be.
[0:42] <ashb> one thing i'd really like is to move away from thisNamingStyleCosIReallyHateIt
[0:42] <kriskowal> although i think we might be let off the hook for sortening "synchronous" to "sync" :P
[0:43] <kriskowal> i don't think that's realistic
[0:43] <kriskowal> oneHump is here to stay
[0:43] <kriskowal> not saying i love it, but we're not going to be able to rename toString or valueOf and it's not worth trying
[0:43] <ashb> we could tho :D
[0:44] <ashb> i'm seriously tempted to have both cases in all my modules
[0:44] <kriskowal> well, you won't get my help
[0:44] <kriskowal> i've got other wars to fight
[0:44] <MisterN> your neighbor?
[0:45] <kriskowal> yeah, killed my puppy
[0:46] <deanlandolt> what about fs and fs.sync?
[0:46] <deanlandolt> meaning, you can nest your sync functions in the fs object if you have them
[0:47] <deanlandolt> os and os.sync don't seem to silly
[0:47] <kriskowal> then you can't separate the implementations
[0:47] <deanlandolt> why not?
[0:47] <kriskowal> require("os") vs require("os-sync")
[0:47] <deanlandolt> err..oh yeah
[0:47] <MisterN> sync should be the default.
[0:47] <kriskowal> many disagree
[0:47] <deanlandolt> and they are legion
[0:47] <kriskowal> they are
[0:48] <kriskowal> which is bizarre, frankly. it's not like it's a new idea.
[0:48] <deanlandolt> if you went on prior art...well, it'd be a no brainer :D
[0:48] <kriskowal> i mean, that they should all appear as a single voice all at once with very little prodding
[0:48] <deanlandolt> heh...yeah, an upswell
[0:49] <deanlandolt> bout time i guess
[0:49] <kriskowal> cgi and databases suppressed the issue for a while
[0:50] <kriskowal> but before that all operating systems had cooperative multi-tasking and event loop servers were one of the most common applications
[0:50] <kriskowal> all of my qbasic games were event loops
[0:51] <kriskowal> so i certainly have sympathies, but i also have synchronous sympathies
[0:51] <kriskowal> the upshot is that i think we should hesitate to draw a line in the sand
[0:51] <deanlandolt> same...to me, ui stuff's always been async, server stuff's always been sync, and i never gave too much thought to it
[0:52] <kriskowal> i've been writing a mud on the side for years; it requires persistent state on the server, so cgi isn't an option; async was the only way to go
[0:52] <kriskowal> and writing with twisted python isn't exactly simple, but i think promises can make these things simple
[0:52] <deanlandolt> so far i've been thrilled with promises...i'm pretty slow and they were so easy to pick up
[1:01] <Dantman> Heh, if I alias a size to length my Blob API is compatible with w3 File API's Blob interface.
[2:16] <Wes-> kriskowal: another idea (not advocating, just suggesting) - require('os').sync
[2:16] <kriskowal> deanlandolt mentioned the idea too
[2:16] <kriskowal> sortof
[2:17] <kriskowal> you could make case for that, but it wouldn't separate the implementations
[2:17] <kriskowal> Wes-^
[2:18] <Wes-> kriskowal: separation of implementation, lack of separation.. that's an implementation detail. :>
[2:18] <Wes-> exports.synx = require("./sync")
[2:18] <kriskowal> could be
[6:00] <paulbaumgart> is there a way to trap SIGTERM with a CommonJS application?
[6:07] <kriskowal> there's no way to trap SIGTERM in any process in any language
[6:07] <kriskowal> SIGINT on the other hand?
[6:07] <kriskowal> i think Wes-- has a way to do that; we've discussed it, but there's been no standards work
[6:08] <kriskowal> paulbaumgart^
[6:09] <paulbaumgart> kriskowal: SIGKILL is the one you can't trap, but you're right, I think I want SIGINT :-)
[6:10] <kriskowal> oh, huh. i wonder how long i've not had that straight in my head
[6:10] <kriskowal> ^\ is SIGKILL?
[6:11] <paulbaumgart> SIGQUIT
[6:11] <paulbaumgart> not sure on the difference, though
[6:14] <paulbaumgart> I'm thinking about making the objj REPL a little more friendly, which is why it came up. I want ctrl-c to delete the current line like most REPLs do, and use EOF (ie. ctrl-d) to end the process.
[6:16] <kriskowal> aye
[6:18] <paulbaumgart> right now, something like that is handled at the JS-engine level?
[6:26] <paulbaumgart> JS exceptions seem like a good model for handling signals
[6:27] <paulbaumgart> that's how python does it, anyway
[6:33] <paulbaumgart> actually, node.js seems to have support for trapping signals; I'll look into how they do it
[7:38] <Wes-> paulbaumgart: what is your repl written in? long story short, you need access to the sigaction or signal system calls
[7:38] <paulbaumgart> Wes-: it's written in javascript running on top of Rhino
[7:39] <Wes-> paulbaumgart: Hmm, I don't know java, but I'm sure it must have a way to trap signals
[7:39] <Wes-> paulbaumgart: what you want is to trap the signal so it does nothing, then look for ^C just like any ordinary key
[7:39] <kriskowal> Wes- did you propose your signal API formally?
[7:40] <kriskowal> it would be good to revisit that, esp after we get an event emitter api
[7:40] <kriskowal> and we still haven't made progress on binary :P
[7:40] <Wes-> paulbaumgart: alternatively, you could use termios routines to change the behaviour of the terminal not to send a SIGINT on ^C
[7:40] <Wes-> kriskowal: No. My implementation can't be generalized to other engines without an event loop - and then it would stop being async
[7:41] <kriskowal> i don't follow
[7:41] <kriskowal> i think it's fine for it to be predicated on an event loop
[7:41] <Wes-> kriskowal: my signal handlers actually interrupt running JS code
[7:41] <kriskowal> ah, yeah; we'd definitely have to make them enqueue events
[7:42] <Wes-> kriskowal: predicating on an event loop radically changes the semantics, though... not of the API, but how it interacts with the underlying system calls
[7:42] <Wes-> OTOH I wouldn't need the current semantics with an event loop and async I/O!
[7:43] <Wes-> My implementation is really quite POSIX/C-esque, in terms of how it interacts with spidermonkey (and the associated potential async hazards)
[7:43] <paulbaumgart> Wes-: interesting idea (using termios); I'm already using rlwrap to make command history work, so that might not be too much of an additional hack.
[7:43] <paulbaumgart> thanks!
[7:43] <Wes-> paulbaumgart: n/p. That's actually the "right" solution from a systems POV as then you can still raise SIGINT other ways
[7:44] <paulbaumgart> even better then :-)
[7:45] <Wes-> I just realized, it's kind of ironic that my signal facility is truly asynchronous
[9:22] <paulbaumgart> hm, so it turns out termios won't do me any good; java will only let me read entire lines from the terminal
[9:22] <paulbaumgart> trapping SIGINT is the only way to solve that, I guess
[9:36] <hannesw> paulbaumgart: if you're trying to read single chars from terminal with rhino/java try jline
[10:01] <paulbaumgart> hannesw: thanks. do you know off-hand if a ConsoleReaderInputStream will let me read a single char directly?
[10:03] <hannesw> If that's the class from jline then: yes
[10:03] <hannesw> helma-ng (currently being renamed to ringojs) implements this in its shell module:
[10:03] <hannesw> http://github.com/ringo/ringojs/blob/master/modules/helma/shell.js
[10:04] <hannesw> there's a read() for single chars and a readln() that takes optional prompt and echo char arguments
[11:07] <paulbaumgart> hannesw: awesome, thanks; now that I've got jline being loaded properly I'll try that
[23:12] <FeatherDark> greetings all! :) i'm trying to apply a $('#btn').click() but it only applys to the first instance of <div id='btn'> can i get it to multiple instances of id='btn' across the page?
[23:14] <FeatherDark> thanks in advance to any of the JS heros who help me! :)
[23:18] <FeatherDark> DOH! use class instead of div is the answer
[23:18] <FeatherDark> thanks

 

 

Logs by date :