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

2010-03-31:

[0:45] <tobie> Three replies I made on the mailing list within the last hour and a half aren't visible despite being advised that they had been published. Anybody knows what gives?
[0:45] <Wes-> I have a 2 hour old message from you in Per-module dependency lists (was [CommonJS] Re: Module Transport Proposal)
[0:46] <Wes-> that's it, though, except stuff from yesterday
[0:47] <Wes-> google must be tired
[0:49] <tobie> Wes-: Hope they weren't lost.
[0:50] <Wes-> tobie: probably not, it happens
[0:50] <Wes-> Ot
[0:50] <Wes-> It's mail
[0:50] <Wes-> look at the spec
[0:50] <Wes-> it has error conditions for "if delivery has not succeed in 5 days,...."
[0:51] <tobie> Wes-: Except I used the web interface.
[0:51] <Wes-> Oh
[0:51] <Wes-> Well, it's still probably writing to a news spool in the back end :)
[0:53] <tobie> OK, well, I'll see about this tomorrow. It's really late out here.
[0:57] <tobie> Added dependency graph generation to modulr as a little fun side project. Here's what it looks like for the Module 1.0 specs: http://bit.ly/9E14AF
[1:06] <jbrantly> tobie: I was having the same issue earlier.
[1:08] <tobie> jbrantly: k, were they finally published?
[1:10] <jbrantly> tobie: yes
[1:12] <tobie> ok, well. let's wait, then.
[5:05] * Dantman wonders why we didn't resolve to defining two separate formats (one for Transport one for hand-coding) before. I thought we already separated require.def and require.define for that reason.
[6:48] <kriskowal> MisterN I reread your Encodings/A; I wrote a "narwhal/encodings" module for node based on their Buffer type. I would like to hear your opinion of the API http://github.com/kriskowal/narwhal/blob/future/packages/narwhal-lib/lib/narwhal/encodings.js
[6:48] <kriskowal> it's similar to your encodings proposal, but there are subtle differences and i'm wondering whether they are subtle errors
[6:48] <ondras> hi kris
[6:48] <ondras> any news on the binary front? :)
[6:49] <kriskowal> some of the differences are accounted for just by the nature of buffer vs bytestring/bytearray
[6:49] <kriskowal> ondras: binary/f is working out really well for me.
[6:49] <kriskowal> i just did a BufferIO and StringIO based entirely on encodings and buffer
[6:50] <kriskowal> i'm going to propose a binary/f/0 for the minimal embedding layer
[6:50] <kriskowal> i've got a decent idea at this point about what part of the spec can be done in the library instead of the embedding http://github.com/kriskowal/narwhal/blob/future/packages/narwhal-lib/lib/narwhal/buffer.js
[6:52] <kriskowal> i think that we should converge on fs-base, io-base, buffer-base, and encodings-base proposals.
[6:52] <kriskowal> and i think we've got good material for those fleshed out already
[6:52] <kriskowal> ondras^
[6:53] <kriskowal> i'm shifting narwhal over from "file" draft 4 to "fs-base".
[6:54] <kriskowal> in my future branch, and the narwhal on node engine
[6:54] <kriskowal> and paring out as much code as possible into the narwhal-lib so it can be used on other engines, eventually entirely on commonjs specs.
[6:55] <ondras> kriskowal: very nice, glad to hear that
[7:02] <ondras> in my opinion, the absence of binary is slowing the progress the most
[7:36] <kriskowal> ondras^ i agree. it's critical we move forward with binary.
[8:11] <Dantman> the absense of stream is the second most slowing issue...
[13:42] <MisterN> ashb: thanks for reminding me of the encoding name. i totally forgot it :)
[13:42] <ashb> no
[13:42] <ashb> np
[13:43] <MisterN> stateful encodings are crazy, but must be supported :)
[13:43] <Wes-> I agree
[13:45] <MisterN> Wes-: you mentioned that usage examples would be good. there are already some examples in encodings/A, but they don't suffice?
[13:45] <Wes-> MisterN: Hmm - I didn't remember them being before, sorry
[13:45] <Wes-> MisterN: Does it cover the same case as the solaris man page?
[13:45] <MisterN> well they are relatively simple
[13:46] <Wes-> i.e. "here is how to convert an entire stream and handle the shift case"
[13:46] <MisterN> Wes-: well Transcoder takes care of that if you use it as explained
[13:46] <MisterN> but maybe people need to be made aware that shift encodings exists
[13:46] <Wes-> MisterN: Oh good - you should probably follow-up and mention some of that
[13:46] <Wes-> But yes, they need to know
[13:47] <Wes-> There might be a need for Transcoder.setInitialShiftState()
[13:47] <MisterN> Wes-: you can simulate it be closing the Transcoder and using a new one
[13:48] <MisterN> -be+by
[13:48] <Wes-> MisterN: That works, closingtranscoder does not close the stream, right?
[13:48] <MisterN> Wes-: it doesn't even know about the stream
[13:48] <Wes-> That's perfect :)
[13:49] <MisterN> Transcoder is low-level, it's not integrated with anything but Binary/B
[13:49] <MisterN> Wes-: i wonder whether the java guys can implement Transcoder easily
[13:50] <Wes-> MisterN: java has iconv, doesn't it?
[13:50] <MisterN> i don't think it has, but i'm not sure
[13:51] <Wes-> does this look powerful enough? http://www.docjar.org/docs/api/gnu/java/nio/charset/iconv/
[13:52] <MisterN> it's not included in java
[13:53] <MisterN> http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/Charset.html
[14:21] <kriszyp> how should this behave? http://gist.github.com/350386
[14:21] <ashb> kriszyp: depends on how much you normalize ids
[14:22] <ashb> in flusspferd and gpsee it would be just once cos we canonicalize id to file on disk and cache based on that
[14:22] <kriszyp> node and narwhal both print twice
[14:22] <ashb> let me check what we do
[14:23] <ashb> oh. stupid GIST
[14:23] <ashb> i ended up with a.js and folder1\c.js
[14:23] <ashb> yeah - flusspferd print's it just the once
[14:24] <ashb> ummm... where's the actual spec for require?
[14:25] <kriszyp> maybe I'll ask on #node.js too...
[14:25] <ashb> kriszyp: but its not really speced what the correct behaviour is there
[14:25] <ashb> i can see arguments for both
[14:25] <kriszyp> yeah
[14:28] <ondras> v8cgi should print only once iirc
[14:45] <JohnnyL> is it possible to compile js?
[14:45] <dom> compile it to what?
[14:45] <JohnnyL> intel assembler.
[14:46] <dom> no idea
[16:05] <MisterN> JohnnyL: in theory, yes.
[16:05] <MisterN> i am not aware of such a compiler, however.
[16:05] <ashb> thats almost what v8's JIT does
[16:05] <ashb> but it still has an interprater and lots of other runtime
[16:19] <MisterN> and it doesn't store the machine code anywhere
[16:19] <ashb> well it does somwehere in memory ;)
[16:20] <MisterN> heh
[22:02] <Wes-> ashb & kriszyp: That is /definitely/ supposed to only print once if my (long ago) reading of Modules/1.0 is correct
[22:02] <Wes-> ashb & kriszyp: I haven't tested GPSEE, but if it printed twice I would consider it a critical-level bug
[22:02] <kriszyp> you talking about my gist?
[22:02] <Wes-> kriszyp: yes
[22:03] * Wes- just got home, reading scrollback
[22:03] <kriszyp> fwiw, felixge from node said that isaacs was doing a refactor that would make node print once
[22:04] <Wes-> sounds about right
[22:05] <ashb> the more interesting case would be when you have a symlinked to b
[22:05] <ashb> cos i naieve impl would then print twice
[22:05] <Wes-> my algorith is roughly to canonicalize based on filesystem to get a unique file handle, then memoize based on the canonical filename
[22:05] <Wes-> I am adding a per-require cache, though, to shortcut the need to canonicalize as often
[22:05] <Wes-> It will map require arguments to canonical filenames
[22:06] <Wes-> and then we use canonical to check the memo
[22:06] <ashb> per require cache?
[22:07] <Wes-> ashb: Right, a require-argument to canonical map. It changes based on require because of relative paths
[22:08] <Wes-> I may push the non-relative map up to the top level require
[22:08] <Wes-> we'll see how annoying that is
[22:09] <ashb> dont quite follow what you mean
[22:11] <jbrantly> Wes-: that's a good idea
[22:12] <Wes-> ashb: sorting out that "./hello" means "/var/surelynx/libexec/gpsee/modules/test/hello" via realpath() involves a blocking system call -- I'm willing to bet that traversing a small Binary Tree will be much faster. (Actually I plan to use a splay tree)
[22:12] <Wes-> jbrantly: Thanks! ;)
[22:13] <ashb> Wes-: oh you onle resolve dirs don't you, not files?
[22:14] <Wes-> ashb: Yes
[22:14] <ashb> makes more sense
[22:14] <ashb> now
[22:15] <Wes-> I'm trying to make require("binary") cost about the same as a variable lookup if the module has already been loaded
[22:15] <Wes-> I suspect I will come very close
[22:15] <Wes-> although, the JIT can probably be smarter about vars than fast natives
[22:15] <jbrantly> Wes-: forgive my ignorance, but what software do you work on?
[22:15] <Wes-> jbrantly: GPSEE
[22:16] <Wes-> jbrantly: http://code.google.com/p/gpsee/
[22:16] <jbrantly> Wes-: thanks
[22:16] <Wes-> jbrantly: How about you?
[22:17] * Wes- realizes this is starting to feel like "a/s/l"
[22:17] <ashb> too old/yes please/somewhere warm
[22:18] <jbrantly> Wes-: Nothing yet. Using node for a hobby project is about all. But I'm wanting to get more involved with CommonJS, and I'm working on a browser-side loader.
[22:19] <Wes-> jbrantly: Awesome! Node doesn't support a lot of CommonJS APIs (yet?) but Ryan has written some really awesome stuff. I'm actually in the middle of ripping off his sockets module.
[22:19] <Wes-> He's also do a good job showing how important async-aware design is in that environment
[22:20] <jbrantly> Yea. Node makes me feel all tingly inside. It's quite nice.
[22:38] <ashb> anyone have comments (good or bad) about http://www.datejs.com/
[22:39] <ashb> oh hmm it messes with built in Date and Number protos
[22:45] <tlrobinson> when did we decide module ids should be camel case? A term must be a camelCase identifier, ".", or "..".
[22:46] <ashb> tlrobinson: aaaages ago.
[22:46] <ashb> but its clearly not the case
[22:47] <tlrobinson> yeah i haven't seen a single camelCase CommonJS module id
[22:47] <ashb> i changed it to be what people do (a-z 0-9 - etc) around 1.0 and got shouted at
[22:47] <ashb> around = some time after
[22:47] <ashb> by one or two people
[22:47] <mikeal> tlrobinson: me neither
[22:48] <ashb> tbh i think it should be far more releaxed.
[22:48] <tlrobinson> yeah i think specifying valid characters is good enough
[22:48] <ashb> [a-zA-Z_][a-zA-Z_0-9-]*
[22:48] <ashb> iwht upper case allowed but very storngly discouraged
[22:48] <tlrobinson> ashb: +1
[22:49] <mikeal> if the spec has a regex that would go a long way in helping package managers provide validation
[23:06] <tlrobinson> oops i should have ready the modules 1.2 thread before my last post

 

 

Logs by date :