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

2010-10-18:

[14:04] <Wes> deanlandolt: caught up on backlog, thanks for notes. Missed you yesterday, was framing a roof, glad I'm not a carpenter, that's hard work
[14:05] <Wes> deanlandolt: require("system") I get, I'm just wondering why jackup uses a free variable named system
[14:06] <Wes> deanlandolt: Let me know when your code hits github. Also, would be interesting if you wrote some benchmarks, I would be interested, for example, in implementing your new spec on top of WebGL typed arrays and comparing perf to a native C object. I bet WebGL TAs would be faster than the C binary/B impl because the JIT can be smarter.
[14:11] <ashb> Wes: cos narwhall originall had (and i guess still does) system as a free var
[14:11] <deanlandolt> Wes: oh, interesting...does v8 have webgl tas too?
[14:11] <deanlandolt> what's jackup using from system?
[14:12] <Wes> deanlandolt: I'm not sure, honestly - it depends on where v8 draws the line between "browser" and "script". But I'd wager 80% chance they do.
[14:12] <Wes> deanlandolt: args
[14:12] <deanlandolt> oh...odd
[14:12] <deanlandolt> that's really interesting...i'll take that up w/ rya
[14:12] <deanlandolt> ryah
[14:13] <Wes> Does jackup successfully launch with /usr/bin/env narwhal on node?
[14:13] <Wes> I changed my local one to:
[14:13] <Wes> #! /usr/bin/env commonjs
[14:13] <Wes> require('jackup').main(require("system").args);
[14:13] <Wes> which seems, y'know, more portable
[14:13] <deanlandolt> he says he keeps going back and forth between mutable and immutable buffers...but what we really need to support the various usecases and mutable length buffers and subsettable buffers (a la node's Buffers)
[14:14] <Wes> deanlandolt: mutable-length buffers have one strong draw back that both Ryan and I will see -- their backing-store address is likely to change
[14:14] <Wes> deanlandolt: This is a potential problem when you're writing the low-level interface code, where C meets JS - i.e. populating I/O buffers
[14:14] <deanlandolt> actually node doesn't have a system module...so we'll be able to patch it with require("commonjs/system") -- that's the point of the lib :)
[14:15] <Wes> Are CommonJS libs now supposed to be in a "commonjs/" namespace?
[14:15] <deanlandolt> hmm, well if that's the case then you can do mutable length in userland
[14:15] <deanlandolt> no, they're not...
[14:15] <Wes> deanlandolt: Or just support both mutable-length and non-mutable-length buffers
[14:15] <deanlandolt> but if we have a commonjs lib we can actually catch non-conformant runtimes
[14:16] <Wes> deanlandolt: non-mutable-length could be as simple an optional param on the constructor, with a throw on a .length setter
[14:16] <Wes> deanlandolt: One thing to realize is that browsers are probably not going to need non-mutable-length buffers, and of course, they don't have the use case
[14:17] <Wes> deanlandolt: So consider length mutability a contract which is optionally enforced with exceptions
[14:17] <deanlandolt> yeah, non-mutable length is easy...the hard part is building a ByteArray on a Buffer...
[14:17] <deanlandolt> but that's easy too
[14:17] <deanlandolt> you just have to do it in userland...you throw a buffer away on every op but oh well...Don't Do That
[14:17] <Wes> Why is building a ByteArray on a Buffer hard?
[14:18] <deanlandolt> well, it's actually not hard...just a little weird
[14:20] <Wes> Ah - that I can see
[14:20] <Wes> Hey, I just realized, es-harmony proxies + WebGL typed arrays would be an awesome way to implement
[14:20] <Wes> and I bet fast
[14:20] <Wes> Of course, proxies don't exist yet :D
[14:20] <Wes> (I think?)
[14:35] <Hadaka> hello! I'm interested in the Promises module
[14:35] <Hadaka> is Promises/B the latest try? Promises/C is mentioned in the wikipedia article
[14:36] <Hadaka> also, are there minimal complete javascript implementations of such a proposal, or?
[14:36] <deanlandolt> Wes: proxies are in SM tip, aren't they?
[14:36] <deanlandolt> Hadaka: one sec ...
[14:36] <deanlandolt> so, here's one implementation: http://github.com/kriszyp/promised-io/blob/master/lib/promise.js
[14:36] <deanlandolt> another is by kriskowal -- trying to dig it up
[14:37] <deanlandolt> http://github.com/kriskowal/q
[14:37] <deanlandolt> the apis are the same, they only differ in a key implementation detail
[14:37] <Wes> deanlandolt: I'm not sure those are es-harmony proxies, or just the internal proxies for object wrapping... Actually, they probably *are* es-harmonky proxies. I really need to update (GPSEE is a few months back)
[14:38] <deanlandolt> yeah, they *are* :)
[14:38] <deanlandolt> they're in ff4
[14:39] <Hadaka> deanlandolt: thanks!
[14:39] <Hadaka> deanlandolt: any short description on what the key implementation detail difference is?
[14:40] <deanlandolt> sure, so kriszyp's promises are ducktypable -- a 'promise' can just be any object that has a then method typeof 'function' ... they means you can share promises from various implementations...
[14:41] <Wes> deanlandolt: That's awesome. GPSEE is about 12-20 man-hours behind updating to FF4-level JavaScript. (Mozilla changed a lot of important APIs in order to squeeze more speed out of the engine)
[14:41] <deanlandolt> kriskowal's promises use an instanceof check -- this means it runs no chance of collision but it also means you can only resolve promises that were created with the same promise lib (moreover the same /instance/ of the q lib -- it's possible two apps may require the same lib in different places)
[14:42] <Hadaka> okay, thanks! I got it
[14:42] <Wes> deanlandolt: since CJS modules are singletons, is that really a problem?
[14:42] <deanlandolt> Wes: yes, a particular module is a singleton but several libs may ship a promise lib
[14:42] <deanlandolt> and we've learned we can't count on some magical top level namespace in most cases :-/
[14:42] <deanlandolt> (e.g. require("system")
[14:43] <Wes> deanlandolt: Ah, I thought you were saying that .. nvm, now I understand
[14:44] <deanlandolt> so i've got a new general approach to interop ... don't ask implementors or other libs to really do anything...if /you're/ writing an interoperable package it's up to /you/
[14:44] <deanlandolt> don't depend on top level namespaces unless you've done a runtime test
[14:44] <Wes> Welcome to the last 30 years of software development? :)
[14:44] <deanlandolt> heh
[14:45] <deanlandolt> yeah, but at least i'm not aware of a single world quite as fractal as javascript :)
[14:45] <Wes> Yeah, JS is a funny place. Thank God for introspection.
[14:45] <Hadaka> I like kriskowal's node implementation much better, even though I'm a fan of duck typing in general
[14:45] <deanlandolt> Hadaka: what do you like about it?
[14:46] <deanlandolt> i haven't looked in a while...is it cleaner? are there more helpers?
[14:46] <Hadaka> deanlandolt: mostly didn't like the otherone - like a hardcoded 100 millisecond errortimeout? wth is up with that?
[14:46] <Wes> Hadaka: *guessing* - avoiding CPU runaway
[14:46] <Hadaka> we?
[14:46] <deanlandolt> kriszyp's very amenable to changes or suggestions
[14:46] <Wes> same reason why setTimeout() on the browser rounds to 100ms
[14:47] <Hadaka> Wes: not the promise implementation's place
[14:48] <deanlandolt> Hadaka: notice it's on the exports object...you can change it
[14:48] <deanlandolt> it should probably use process.nextTick if on node
[14:50] <deanlandolt> Hadaka: i can patch that pretty quick...anything else you noticed?
[14:53] <Wes> deanlandolt: Funny question, does node support any asynchronous events? That interrupt the active script, go do something, then resume?
[14:54] <deanlandolt> no, it used to but they dropped it
[14:54] <Wes> Any idea what the use-case was? I'm wondering how important that feature is in GPSEE
[14:54] <deanlandolt> at least, i think you could have modeled behavior on the promise.wait fn they had
[14:54] <Wes> We use it mostly for require("signal").onHUP = function () { print('hello') } kind of stuff
[14:55] <deanlandolt> hmm...i guess i'm not sure what an async event is then...
[14:55] <Hadaka> deanlandolt: I also like the clean implementation of Method and it's usage in kriskowal's implementation
[14:55] <deanlandolt> how does require("signale").onHUP work?
[14:56] <Hadaka> also, kriskowal's implementation is shorter, even though kriszyp's implementation does quite a few things more
[14:56] <Wes> deanlandolt: basically, it will interrupt running script, potentially mid-statement, then resume it after the signal handler runs. So, not an event-loop, basically preemptive events. With all the associated correctness hazards.
[14:57] <deanlandolt> Hadaka: yeah, a lot of that stuff in kriszyp's implementation could be moved somewhere else
[14:57] <Hadaka> hmmh, it looks like kriszyp's implementation doesn't even export the "method" function??
[14:58] <Hadaka> ...or defined, or ref
[14:58] <deanlandolt> Wes: in that case, no i don't think node every supported that
[14:58] <deanlandolt> Hadaka: what's the use-case?
[14:59] <deanlandolt> (of exporting Method?)
[14:59] <Hadaka> deanlandolt: use case is conforming to Promises/B :) not sure yet which functions I will need
[14:59] <Wes> deanlandolt: Okay. I've been using it for mostly stuff like "hey, it's time to re-read the config file", but it could be used with a reactor instead. My concern, actually, is that if I pop a reactor in that async interruptions + reactor will become confusing and/or buggy
[14:59] <Hadaka> actually, kriskowal's doesn't export method either, only Method
[14:59] <deanlandolt> Hadaka: ah, i didn't realize kriskowal had put up a proposal
[15:00] <deanlandolt> promises/b has an awful lot of baggage :-/
[15:00] <Hadaka> ach, my bad!
[15:00] <deanlandolt> then and when should be all you need
[15:00] <deanlandolt> i don't understand why we need to specify all this noise
[15:01] <Hadaka> I thought Promises/B was a later version of Promises/A (being ignorant of the commonjs process) - instead they are alternative proposals?
[15:01] <deanlandolt> Wes: why do you need to do interruptions?
[15:01] <deanlandolt> Hadaka: yeah, they're competing proposals...we need a clear narrative to describe all this stuff :-/
[15:01] <deanlandolt> i wasn't aware of the existence of promises/b actually
[15:02] <Wes> deanlandolt: Short reason? I'm used to coding that way. (wait for activity in a loop, if I get a HUP signal, re-read config file, etc) Long reason? Probably that I don't have a reactor
[15:03] <Wes> deanlandolt: I implemented that signal module -- very cleverly -- before I really grokked the event loop paradigm, now I'm wondering if it was such a good idea. ;()
[15:03] <Wes> or
[15:03] <Wes> er
[15:03] <Wes> ;)
[15:04] <deanlandolt> Wes: heh...yeah, the rumor is it's /reaaaaaaally/ hard to do :D
[15:04] <deanlandolt> (interruptions, that is)
[15:04] <Hadaka> Wes: just about every language handles signals in a non-interrupt way, by a queue of some sort - even linux has support for signalfd for sane handling of signals
[15:06] <Hadaka> deanlandolt: do you know why kriskowal has all these "get" "put" "del" methods there? isn't it just simpler to resolve the object and deference it directly?
[15:06] <deanlandolt> yeah, because this all is derived from tyler close's ref_send lib which specs all this
[15:06] <Wes> deanlandolt: Hard is the understatement of the century, it's not even possible to do it without specific JS engine hooks that are VERY deep (right down the interpreter loop) - and then you have to contend with some very interesting heisenbugs. Like, what happens if you're in the middle of ++ ing a variable that your signal handler changes when it gets called? (result: undefined)
[15:07] <deanlandolt> it allows you to do crazy stuff like pipelining far-references
[15:07] <Wes> Hadaka: *nod* - I'm aware of that technique, I'm just trying to determine if my current technique has significant value or not
[15:07] <Wes> My current technique comes very close to approximating POSIX signals semantics that you get in C
[15:08] <deanlandolt> Wes: people have moved away from it for sure...but i'm not one to say whether something has value...one value could certainly be in killing runaway events
[15:08] <Hadaka> deanlandolt: something like x.get('foo').get('bar').get('baz')?
[15:08] <Wes> deanlandolt: That's a good point - resetting a malfing reactor :)
[15:08] <deanlandolt> Hadaka: yeah, and doing put and del as well (not in the REST way, but in the [[Put]] and [[Delete]] way)
[15:09] <Hadaka> deanlandolt: right
[15:09] <deanlandolt> and i guess post is [[Call]]
[15:10] <deanlandolt> i haven't really ever groked the value of the far-reference method call stuff...plus the value all goes away when we get proxies, which won't be /too/ long now
[19:34] <Hadaka> dammit, my javascript is way too weak - what's a good channel for asking silly javascript questions not related to anything in special?
[19:34] <Wes> Hadaka: ##javascript
[19:35] <Hadaka> Wes: thanks
[19:53] <deanlandolt> Wes (et al): http://github.com/deanlandolt/commonjs
[19:59] <Wes> Why do I keep trying to use svn to clone repos on github?
[20:00] <Wes> I think we should start a project and call it the Patchy CommonJS
[20:00] <Wes> See if we can get google pagerank from sounding like Apache Commons
[20:02] <Wes> deanlandolt: bug report? Why are you starting modules (as opposed to programs) with #! ?
[20:03] <Wes> That blows up over here, since that is invalid javascript
[20:23] <deanlandolt> oh, sorry...i just moved my test stuff over :-/
[20:23] <Wes> :)
[20:24] <Wes> deanlandolt: FWIW - I would be willing to ship something like this with GPSEE
[20:24] <deanlandolt> i had it all in a tests dir but was having issues w/ relative requires going up above the root again
[20:24] <Wes> At least once it's, you know, not brand new
[20:24] <Wes> Call it maybe commonjs-stdlib or something, though
[20:24] <deanlandolt> heh...well, yeah, this isn't close to finished...it's barely close to working :)
[20:25] <deanlandolt> yeah...i don't think everyone will take kindly to stomping all over the name...
[20:25] <deanlandolt> but we need /something/ that lets us say require("commonjs")
[20:25] <Wes> make sure you point out that stdlib stands for "Backwards is Landolt, Dean, Trying to Standardize"
[20:25] <deanlandolt> hmm, maybe require("stdlib") would be fine
[20:25] <deanlandolt> (but that may be in use)
[20:26] <deanlandolt> yeah, i'm not even trying to really standardize anything...just provide a lib that can bridge the various implementations
[20:26] <Wes> once upon a time standards were named after the implementors leading the charge
[20:26] <Wes> LIM EMS -- "Lotus, Intel, Microsoft Expanded Memory System"
[20:26] <deanlandolt> so that other libs can require("commonjs")
[20:27] <deanlandolt> heh, that's not a bad idea (like Binary/F/Wes)
[20:28] <deanlandolt> the point is this doesn't actually standardize /anything/ ... just provides a binary impl that can use our current standards (Binary/B, Binary/F -- eventually all Binary/* and node.js Buffers)
[20:28] <deanlandolt> same for fs
[20:29] <deanlandolt> so, you can use ByteString and ByteArray if you're down w/ Binary/B, or Buffer if you're down w/ Binary/F or node...but the nice part is you can use both in either (with the only stipulation being that if you're on Binary/B you'll never be able to buffer.subset anything)
[20:30] <Wes> commonjs-clib?
[20:30] <Wes> "common lib"
[20:31] <Wes> "compatible lib" :P
[20:31] <deanlandolt> require("compat")
[20:31] <deanlandolt> hmm, okay, i think i'm convinced...it'll be a lot less controversial to not call it commonjs, that's for sure
[20:32] <deanlandolt> perhaps there could also be a commonjs package that could allow you to choice your compatibility layer of choice...so we could still do a require("commonjs") that way
[20:34] <Wes> how about deepr?
[20:35] <deanlandolt> deepr?
[20:35] <Wes> Dean's Exceptionall Excellent Portable Runtime
[20:35] <deanlandolt> heh
[20:35] <deanlandolt> Dean's Outstanding Portable Environment
[20:35] <Wes> heheh
[20:35] <Wes> require("very-commonjs")
[20:36] <Wes> deanlandolt: ^^^ that's descriptive and non controversial
[20:36] <deanlandolt> true
[20:39] <deanlandolt> why not require("patch-commons") per your initial suggestion
[20:40] <deanlandolt> require("js-commons") could be another non-controversial name
[20:44] <Wes> deanlandolt: patch-commons was sort of a joke, but not completely. "
[20:44] <Wes> deanlandolt: "js-commons" is actually not bad
[20:44] <deanlandolt> yeah, i really like require("commons")
[20:44] <deanlandolt> require("commons/binary").shim()
[20:44] <Wes> I also like "monkeys"
[20:44] <Wes> But I'm funny that way ;)
[20:45] <deanlandolt> it's completely unused, and doesn't really have any real meaning in javascriptland
[20:45] <Wes> not only that, it parallels well with ASF commons
[20:45] <deanlandolt> it's commonjs w/o the j...hell, j stands for "java" and we're not into that
[20:45] <Wes> HEH!
[20:45] <deanlandolt> yeah, that's kinda the idea...and it looks right
[21:35] <deanlandolt> Wes: i just pushed to a new repo: now it's http://github.com/deanlandolt/commons -- let me know if you have any trouble (i don't have a gpsee env handy so i can't test gpsee until i get home tonight)
[22:05] * Wes- is feeling really good about browser modules today
[22:06] <Wes-> I think framing the discussion as module loader + module memo reader is really the right approach
[22:06] <Wes-> It has really helped me clear my mind
[22:06] <deanlandolt> heh...since i'm no longer angling for my package to be "commonjs" i can provide some nice shims to bootstrap all that :)
[23:04] <Wes-> Who here believes that automatic dependency resolution is a mandatory Browser-Modules feature?

 

 

Logs by date :