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

2010-01-06:

[1:37] <tlrobinson> ondras: do you know what this commit to narwhal is about: http://github.com/veged/narwhal/commit/b0950e15b9056c168cb21d4e0dc8e52d58535348
[1:37] <tlrobinson> assigning to global doesn't actually make it global?
[6:00] <cadorn> ondras: re Firefox + Firebug crashing, a lot of work has gone into firefox to make firebug work better, they should be pretty open to receiving a crash report with Firebug installed, if not send it to the firebug mailing list
[6:30] <ondras> cadorn: I already sent a crash report :)
[6:31] <ondras> tlrobinson: it is certainly related to recently refactored per-module require, but I don't understand the code linked :)
[7:50] <keeto> ondras: there's no stderr in v8cgi?
[7:51] <ondras> keeto: system.stderr(text)
[7:51] <keeto> ah, it's not in the wiki. x)
[7:51] <ondras> true, waiting for fs to get finally standardized
[13:48] <ashb> gah - some people really like fork bombs in your archinves dont you
[15:44] <SubtleGradient> ahoy all
[15:45] <SubtleGradient> what's the current "best practice" for writing javascript for use on the CLI that will work cross-platform and also work as a CommonJS module and on the web without modification?
[15:45] <SubtleGradient> does anyone currently do that?
[15:46] <SubtleGradient> i imagine the dependency management would be one of the trickiest issues
[15:46] <deanlandolt> SubtleGradient: "without modification" is a tall order...commonjs modules need a tiny amount of boilerplate
[15:46] <SubtleGradient> surely
[15:46] <SubtleGradient> alrighty then.
[15:47] <SubtleGradient> I guess I shall take it upon myself to devise a minimalistic example of how to do it in the safest possible way
[15:48] <deanlandolt> there are some examples floating about
[15:48] <deanlandolt> i'll see if i can't dig something up off the ML
[15:48] <SubtleGradient> sweet!
[15:49] <SubtleGradient> I'll update the TextMate JavaScript bundle to support more cross-environment js soon
[15:49] <deanlandolt> awesome
[15:50] <SubtleGradient> what percentage of js devs use TM do you know?
[15:51] <deanlandolt> not a clue...seems popular though
[15:51] <deanlandolt> (i don't develop on a mac...almost wish i did for TM)
[15:51] <Wes-> "without modification" isn't as hard if you have a good CommonJS module loading system
[15:52] <Wes-> But, I'm not aware of any that exist -- yet
[15:52] <SubtleGradient> I'm doing my best to devise a quasi-universal solution
[15:52] <SubtleGradient> with only minimal boilerplate
[15:52] <Wes-> although eval(boilerplate + syncXHR("package")) would work fine
[15:53] <Wes-> My thoughts revolve more around a smarter webserver though
[15:53] <Wes-> which would allow the server to fire multiple modules in one HTTP request
[15:53] <SubtleGradient> you should be able to universalize almost any js very easily. that's the goal
[15:53] <Wes-> I briefly outline this approach in early dec on the mailing list
[15:53] <Wes-> SubtleGradient: Yes, it's very easy, but you have to at a minimum provide a closure around modules for browser impl
[15:54] <SubtleGradient> right
[15:54] <SubtleGradient> but I figure a closure is best practice anyway
[15:55] <SubtleGradient> Wes-: would you happen to have a link to that thread in the ML?
[15:55] * Wes- searches
[15:55] <SubtleGradient> searching the ML is painful
[15:56] <SubtleGradient> do you know if it's on nabble yet?
[15:56] <deanlandolt> searching gmail works
[15:56] <SubtleGradient> sure, if you have been on the list for a while ;)
[15:56] <deanlandolt> :)
[15:56] * SubtleGradient is still a pathetic n00b
[15:57] <SubtleGradient> ?when it comes to CommonJS
[15:57] <deanlandolt> SubtleGradient: 12/4/09 looks like the thread Wes- is talking about
[15:58] <deanlandolt> called "Importing Modules" ...should be easier to find on google groups
[15:59] <SubtleGradient> anyone know if anyone is working on a js packaging system?
[15:59] <SubtleGradient> like rubygems
[15:59] <deanlandolt> there's been some talk...ashb registered the awesome "packag.es" domain
[15:59] <SubtleGradient> nice!
[15:59] <SubtleGradient> I own bundleforge.com
[15:59] <deanlandolt> cool
[16:00] <SubtleGradient> and I've been wanting to do something with it for a while
[16:00] <deanlandolt> there's tusk as a "packaging" system...
[16:00] <deanlandolt> but as far as a package catalog, it's manually managed right now
[16:00] <SubtleGradient> the MooTools community recently released a Forge
[16:00] <deanlandolt> the package format that looks like it's about to be ratified may jumpstart that process
[16:00] <SubtleGradient> and a script comment header format for dependency mapping
[16:00] <deanlandolt> i saw something about that
[16:01] <SubtleGradient> the advantage of our dependency system is that it's decoupled from the filesystem. e.g. a single file may provide multiple things. So you depend on a "thing" instead of a specific file
[16:02] <SubtleGradient> but ofc with that comes extra complication for parsing and building and such
[16:03] <deanlandolt> SubtleGradient: have you seen this: http://wiki.commonjs.org/wiki/Packages/0.1
[16:03] <SubtleGradient> yes
[16:03] <SubtleGradient> looks like a good standard
[16:03] <SubtleGradient> i'm sure there will be a way to bridge the gap between the separate standards
[16:03] <deanlandolt> how do you depend on a "thing" in mootools? is that thing dereferencable?
[16:04] <SubtleGradient> define: dereferencable
[16:04] <deanlandolt> you can fetch it
[16:04] <deanlandolt> a url, for instnace
[16:04] <deanlandolt> even if not an http:// schemed url
[16:04] <SubtleGradient> currently there is no packaging system. it relies on packageID:tag:thing
[16:05] <deanlandolt> who assigns the packageID?
[16:05] <SubtleGradient> whoever creates the package
[16:06] <deanlandolt> what keeps them from accidentally (or maliciously) stepping on someone else's id?
[16:06] <SubtleGradient> we'll have to enforce some kind of unique naming for the forge
[16:06] <SubtleGradient> probly already do
[16:06] <SubtleGradient> it'll probly end up being similar to how github works
[16:06] <SubtleGradient> username-reponame
[16:06] <deanlandolt> utlimately things always seem to fall back on centrally managemed namespaces
[16:07] <deanlandolt> (even the internets)
[16:07] <SubtleGradient> actually, there is a current plan for working around that too
[16:07] <SubtleGradient> where you can have a local config file that can override package names
[16:07] <SubtleGradient> and create keywords that you define the actual package for
[16:08] <Wes-> SubtleGradient: http://groups.google.com/group/commonjs/browse_thread/thread/57a46efdcdfce122/1234bc8e989f460c?lnk=gst&q=wes%40page.ca+importing+modules#1234bc8e989f460c
[16:08] <SubtleGradient> which would allow you to override a certain package with your own edge build or something
[16:08] <SubtleGradient> Wes-: thanks
[16:08] <SubtleGradient> Wes-: what's your name on the ML?
[16:09] <deanlandolt> SubtleGradient: Wes
[16:09] <Wes-> SubtleGradient: wes@page.ca
[16:09] <SubtleGradient> ah :D
[16:09] <Wes-> there should be a post in there with a sample shell script
[16:09] <Wes-> having a hard time finding it
[16:10] <SubtleGradient> the mootools community is at the verge of becoming very active in the non-web use of js
[16:10] <Wes-> SubtleGradient: http://groups.google.com/group/commonjs/browse_thread/thread/11c6f25c46b3837b/52d62074327d0d56?lnk=gst&q=wes%40page.ca+bin+sh#52d62074327d0d56
[16:10] <Wes-> ^^ thread of most interest?
[16:11] <SubtleGradient> I'm hoping to help define the best practices that we recommend to our whole community
[16:11] <Wes-> look for post from me on Dec 22
[16:11] <Wes-> SubtleGradient: what's your non-web environment?
[16:11] <SubtleGradient> brb 1sec
[16:11] * Wes- doesn't know anything about mootools
[16:11] <Wes-> Does it have anything to do with lambda-moo?
[16:13] <SubtleGradient> phonecall wiht boss, sorry
[16:13] * Wes- hates those
[16:13] <inimino> probably not
[16:13] <ashb> moo-tools is a browser js framework like jquery, dojo, prototrype yui etc
[16:13] <ashb> (or at least it was, it might be a bit more general purpose now)
[16:26] <Wes-> OIC
[16:43] <SubtleGradient> back, sorry
[16:44] <SubtleGradient> ashb: Wes-: Yeah, MooTools is primarily a client-side framework. But the core of it is very general purpose.
[16:44] <SubtleGradient> We're already running serverside in a number of environments
[16:44] <SubtleGradient> and on the desktop in a number of places
[16:45] <SubtleGradient> plugins and extensions for certain desktop apps and such
[16:45] <SubtleGradient> MooTools is most often compared with jQuery, but the DOM is only a small fraction of the scope of MooTools
[16:46] <Wes-> general purpose stuff like what? (got a link?)
[16:47] <SubtleGradient> http://mootools.net/core
[16:47] <SubtleGradient> there's a core builder with all the "core" modules
[16:47] <keeto> http://www.ape-project.org/, http://raccoon.keetology.com/
[16:47] <SubtleGradient> it's a modular framework that can combine multiple focused parts into a single package
[16:48] <SubtleGradient> the corest core is native extensions and a very flexible Class implementation
[16:49] <Wes-> ah, neat. I've seen APE before. Nice kit.
[16:49] <SubtleGradient> a very consistent api is the most important goal of the project
[16:50] <SubtleGradient> to unify development across all platforms
[16:50] <SubtleGradient> and to extend javascript itself with a layer of functionality normally only found in scripting languages like Ruby and Python
[16:51] <SubtleGradient> while sticking closely to the spirit and functionality of javascript itself
[16:51] <Wes-> I'm all for that!
[16:51] <SubtleGradient> e.g. our Class implementation uses native prototype inheritance
[16:52] <SubtleGradient> but it makes it a lot easier to use
[16:53] <SubtleGradient> e.g. you can add an object or array as a property when defining a class. And when you instantiate that class it'll clone the object as an instance object instead of pointing to that single global object for all instances
[16:53] <ondras> SubtleGradient: how do you support calling parent/super methods?
[16:53] <keeto> this.parent() for parent methods.
[16:53] <SubtleGradient> when you create the class or implement new methods onto a class it wraps each function only once
[16:54] <SubtleGradient> so that each instance properly inherits using prototypical inheritance
[16:54] <Wes-> So... you are implementing classical inheritance?
[16:54] <SubtleGradient> not exactly, no
[16:54] <ondras> keeto: so each method is aware of its "parent"?
[16:54] <SubtleGradient> but it does have many of the features found in classical inheritance
[16:55] <SubtleGradient> there's subclassing and mixins
[16:55] <SubtleGradient> no multiple inheritance since JavaScript doesn't do that
[16:55] <SubtleGradient> but you can subclass a subclass
[16:55] <SubtleGradient> and mixin multiple objects into your classes
[16:55] <keeto> ondras: this.parent() is a method implemented in classes that inherit directly, and it checks the caller method's name to see if a corresponding one is available in the chain and calls that.
[16:56] <ondras> keeto: okay, so arguments.callee.caller, right?
[16:56] <keeto> yeah.
[16:56] <SubtleGradient> no, since that isn't cross-platform
[16:56] <SubtleGradient> that was recently upgraded to use something else
[16:56] <SubtleGradient> I'll find the code
[16:56] <ondras> thx
[16:57] <SubtleGradient> http://github.com/mootools/mootools-core/blob/2.0wip/Source/Class/Class.js
[16:57] <keeto> ooops, yeah.
[16:57] <keeto> mistook the caller property for callee.caller
[16:57] <SubtleGradient> back when it was safe to use in all standard browsers we did use some fancy caller stuff
[16:58] <SubtleGradient> but that became less safe in later browsers
[16:58] <keeto> air was one catalyst for removing it, right?
[16:58] <SubtleGradient> iirc, ya
[16:59] <_m4n_> Happy new year and long live SSJS
[16:59] <ondras> this.$caller.$name
[16:59] <ondras> hmm
[16:59] <ondras> how does $caller and $name get created?
[17:00] <SubtleGradient> http://github.com/mootools/mootools-core/blob/2.0wip/Source/Class/Class.js#L56-67
[17:01] <SubtleGradient> took me a while to finally understand how Class works
[17:01] <_m4n_> I am working on a snmp2json gateway in order to display snmp values and tables in browsers. Is someone already working on that?
[17:01] <SubtleGradient> it's probly the most magical code we have
[17:01] <keeto> srly.
[17:02] <keeto> hard to wrap your head around. x)
[17:02] <SubtleGradient> helped me become a better JS coder though
[17:02] <SubtleGradient> finally completely grokking the prototype and closures
[17:02] <SubtleGradient> brb, call
[17:06] <ondras> SubtleGradient: what do I need to download in order to try the code you linked?
[17:06] <SubtleGradient> teh 2.0 fork you'll have to get from github. but the latest stable version can be built from mootools.net
[17:07] <SubtleGradient> ondras: http://mootools.net/core
[17:07] <keeto> latest release already includes that version of Class.js
[17:07] <SubtleGradient> build a copy with whatever features you need
[17:07] <SubtleGradient> yeah, only a few extra features in 2.0
[17:08] <ondras> because it looks to me
[17:08] <ondras> like each class gets its own version of inherited method
[17:08] <ondras> so child.prototype.method != parent.prototype.method
[17:09] <SubtleGradient> ondras: also mooshell.net to just play with it
[17:09] <ondras> cool!
[17:10] <keeto> ondras: not really.
[17:10] <keeto> because if class Y extends class X, Y.prototype.methodFromX should exist, unless directly created.
[17:11] <keeto> and if that's the case, then you're right. :)
[17:11] <ondras> err
[17:11] <ondras> for the sake of simplicity
[17:11] <ondras> how do I create X and Y and X.prototype.something() in mootols? :)
[17:11] <keeto> new Y().a === X.prototype.a; //true
[17:12] <ondras> "in mootools"
[17:12] <ondras> using that Class() thingy
[17:12] <keeto> var X = new Class({ a: function(){} }); var Y = Class({ Extends: X }); new Y().a === X.prototype.a; // true
[17:13] <Wes-> ondras: can you try sshing in to my mac?
[17:13] <ondras> keeto: the trouble I see is that there is no Y.prototype.a
[17:13] <keeto> yep, but it inherits from X. :)
[17:13] <Wes-> ondras: awesome, thanks!
[17:13] <ondras> Wes-: works, cool, thanks! :)
[17:14] <ondras> keeto: well... okay, thanks for explanation :)
[17:14] <ondras> nevertheless, I prefer Y.prototype.a == X.prototype.a
[17:15] <keeto> you can't if you're inheriting directly.
[17:15] * ondras already spent many hours trying to emulate classical inheritance while maintaining full prototype philosophy :)
[17:16] <ondras> var X = OZ.Class(); X.prototype.a = function(){}; var Y = OZ.Class().extend(X); Y.prototype.a == X.prototype.a :)
[17:16] <ondras> dtach, dinner
[17:18] <_m4n_> How do CommonJS fit with Dojo ( or the opposite )?
[17:18] <Dantman> Completely different scope
[17:19] <Dantman> Dojo is a JS library, CommonJS is a standardization group
[17:44] <_m4n_> Dantman: yes, Dojo is a JS library but do they target also server side JS for the next release like mootools do? if so, will they comply with CommonJS?
[17:57] <CrypticSwarm> _m4n_: I think dojo has something called persevere that is server side, no idea if it is commonjs compliant though
[17:57] <deanlandolt> CrypticSwarm, _m4n_: it's commonjs (its author kris zyp is heavily involved in standards here)
[17:58] <deanlandolt> but it's not really a /dojo/ project as much as tangentially related to dojo (it's a dojo foundation project)
[17:58] <SubtleGradient> dojo foundation != dojo toolkit
[17:59] <CrypticSwarm> deanlandolt: ahhh thanks
[17:59] <SubtleGradient> like MooTools != core or more or slick or slickspeed, etc?
[18:00] <SubtleGradient> 99% of the time when people say "dojo" they mean dojotoolkit. Same for MooTools and MooTools-core
[18:00] <deanlandolt> or apache
[18:00] <SubtleGradient> right
[18:01] <kriszyp> Dojo has supported some level of functionality in Rhino for some time. There is a lot of discussion about how module loading will work in Dojo 2.0, but I am not sure yet if CommonJS module support will be added
[18:02] <CrypticSwarm> I only heard about perservere from Dylan Schiemann at a conference, and it sounded like most of the work with perservere was paired with dojo
[18:03] <kriszyp> I'd imagine at some point we (dojo) would create some type of loader mechanism to make it more friendly with commonjs
[18:29] <_m4n_> I really think that CommonJS can become the next big thing if something like wavemaker comes from it
[21:07] <Wes-> gelatin / andy chu in here?
[22:02] <Wes-> fs-base touch - how do we handle ms on filesystems which don't support? truncate or round?
[22:03] <tlrobinson> SubtleGradient: i use TM
[22:04] <tlrobinson> SubtleGradient: do you maintain the JS TM bundle or something? jan lenhardt started a CommonJS bundle too
[22:04] <SubtleGradient> yeah
[22:04] <SubtleGradient> I haven't updated the official one in a while and have been maintaining it on github instead
[22:05] <SubtleGradient> now that the official bundles are moving to github I'll be pushing to the official ones again
[22:05] <SubtleGradient> also I maintain JS Tools
[22:06] <SubtleGradient> http://github.com/subtleGradient/javascript.tmbundle http://github.com/subtleGradient/javascript-tools.tmbundle
[22:06] <SubtleGradient> tlrobinson: do you have a link to the commonjs bundle?
[22:07] <tlrobinson> http://github.com/janl/CommonJS.tmbundle
[22:07] <tlrobinson> not much there yet
[22:07] <SubtleGradient> thx
[22:08] <SubtleGradient> when I go to add more CommonJS stuff I'll fork and contribute to his
[22:11] <SubtleGradient> my javascript bundle has codecompletion and tooltips from QuirksMode.org
[22:11] <SubtleGradient> used with permission
[22:12] <SubtleGradient> http://subtlegradient.com/articles/2008/09/21/new_textmate_code_completion_and_smart_tooltips.html
[22:37] <Dantman> Wes-, there are filesystems that don't support updating a modified timestamp?
[22:37] <Dantman> Java doesn't seam to think so

 

 

Logs by date :