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

2009-12-16:

[0:28] <ashb> http://semver.org/
[1:58] <zilenCe1> is there a way to set a name for a module different from the identifier?
[2:11] <zilenCe> anyone up?
[2:24] <tlrobinson> ashb: +1 to semvar.org
[2:25] <tlrobinson> we should recommend or require it for commonjs packages
[2:26] <zilenCe> stupid question: in both v8cgi and node.js it seems to work to put stuff on "this" inside a module and it is actually available in the global namespace then
[2:26] <zilenCe> I guess this should/will be forbidden at some point, right?
[2:33] <tlrobinson> zilenCe: afaik the only platforms that prevent non-explicit global variables are helma ng (?) and narwhal on rhino (disabled by default)
[2:33] <tlrobinson> it's not prohibited in the spec
[2:33] <zilenCe> oh
[2:33] <tlrobinson> but it's not allowed
[2:33] <zilenCe> haha
[2:34] <zilenCe> will it be removed at some point or will it stay forever?
[2:34] <tlrobinson> you'll have to ask those implementations
[2:34] <tlrobinson> or do you mean the spec?
[2:34] <tlrobinson> it's not easily implementable in the browser
[2:34] <zilenCe> both
[2:35] <zilenCe> I actually do not care about browsers in this case
[2:36] <cpojer> mh
[2:36] <tlrobinson> i should say, to be a commonjs compatible module you aren't allowed to assume "this.foo = bar" or "foo = bar" will be made global
[2:36] <tlrobinson> thus you should *always* use var
[2:36] <cpojer> sure
[2:36] <tlrobinson> i.e. the behavior of those two cases is undefined
[2:37] <cpojer> when in the main code I put something on the global namespace, am I allowed to assume its available in modules on this?
[2:37] <tlrobinson> up to the implementation
[2:37] <cpojer> sorry if any of the questions is stupid, most of this is just pretty new
[2:37] <tlrobinson> i don't think the spec allows you to put things in the global
[2:38] <cpojer> heh
[2:38] <tlrobinson> narwhal explicitly allows it via the global object
[2:38] <tlrobinson> "global"
[2:38] <cpojer> v8 is ok too
[2:38] <cpojer> v8cgi I mean
[2:38] <tlrobinson> http://wiki.commonjs.org/wiki/Modules/1.1
[2:39] <tlrobinson> does no mention "global"
[2:39] <tlrobinson> so i presume that was a narwhal extension
[2:39] <cpojer> yah
[2:39] <tlrobinson> it wouldn't be allowed in a "secure" sandbox though
[2:39] <cpojer> I think the specs should be more specific about that stuff
[2:39] <cpojer> but I suppose it is sometimes hard to agree on that kind of stuff
[2:40] <tlrobinson> so yeah you shouldn't assume you're allowed to create globals, unless you only plan to use one platform and you're not releasing the code as a libraryu
[2:40] <cpojer> right
[2:43] <cpojer> I have seen narwhal having a package manager, is there actually a spec for something like that? Mainly I see module ids as paths
[2:43] <cpojer> but I want something like library/module
[2:43] <cpojer> well I could do a library specific loader I suppose
[2:44] <cpojer> whats the preferred solution?
[2:53] <tlrobinson> we usually just put the library in a directory
[2:53] <tlrobinson> i.e. lib/jack/whatever.js
[2:53] <tlrobinson> require("jack/whatever")
[2:53] <cpojer> right
[2:53] <cpojer> and internally you do ./whatever
[2:53] <cpojer> ?
[2:53] <tlrobinson> yes
[2:54] <cpojer> right
[2:54] <tlrobinson> what's wrong with that?
[2:54] <cpojer> well I guess it makes more sense when you use git submodules
[2:54] <cpojer> just at the moment I have two files in different folders
[2:54] <cpojer> so I have different paths to the modules
[12:19] <ashb> tlrobinson: in hippo "foo = bar" will give you a strict mode warning. (just an fyi)
[15:24] <ashb> kriszyp: you've got mixed tabs+spaces in jsgi-node.js btw
[15:25] <ashb> makes reading it on github a bit of a pain
[15:30] <kriszyp> did I mention it was "rough" :/
[15:50] <deanlandolt_> kriszyp: i likey!
[18:42] <nrstott> what's the current status of Node and JSGI?
[18:42] <nrstott> is there a JSGI adapter for Node?
[18:43] <deanlandolt_> nrstott: kriszyp has this: http://github.com/kriszyp/jsgi-node
[18:43] <deanlandolt_> i'm not sure where it's at
[18:44] <nrstott> kriszyp, any input on that?
[18:44] <kriszyp> not testing/working at all
[18:44] <kriszyp> I was just about to do some work on it though
[18:45] <nrstott> nice
[18:45] <kriszyp> any thoughts on my email?
[18:46] <deanlandolt_> kriszyp: other than the fact that node's apis aren't yet stable (and probably won't be until at least feb now) i think it's a spectacular idea
[18:46] <kriszyp> well, thats a good thing
[18:46] <deanlandolt_> perhaps we could get some commitment from ryah_away on an http api
[18:47] <kriszyp> I wouldn't to have to work around a frozen API if we standardizing this in commonjs
[18:47] <nrstott> i really want Bogart to run ontop of Node
[18:47] <nrstott> and soon
[18:47] <deanlandolt_> kriszyp: good point
[18:47] <kriszyp> I really want pintura to run on top of node
[18:47] <nrstott> and still have it be able to run ontop of the narwhal stack
[18:47] <kriszyp> exactly
[18:47] <nrstott> so that means that I may be doing some work on Jack to break its narwhal dependence
[18:47] <kriszyp> cool
[18:47] <deanlandolt_> nrstott: i'd be happy to help
[18:48] <kriszyp> and we are fundamentally in a better situation if we can run our frameworks on node and other jsgi platforms
[18:48] <deanlandolt_> multipart parsing is one place
[18:48] <nrstott> deanlandolt_, awesome.
[18:49] <nrstott> so what is your generla plan at the moment, kriszyp
[18:49] <deanlandolt_> nrstott: i've already started updating the jack to 0.3...i'm in the midst of some firefighting at work but hope to dedicate more time to that this week and weekend
[18:49] <deanlandolt_> (oh, and kriszyp's already done most of the work -- it's just some middleware that's hanging around)
[18:49] <kriszyp> general plan? like with my life or pintura, or JSGI adapters for node? :)
[18:49] <deanlandolt_> heh
[18:49] <nrstott> JSGI adapters for node, and your life ;0
[18:49] <kriszyp> I want to write the JSGI adapter for Node so pintura can run on it
[18:50] <kriszyp> Pintura is already fully async ready (promise support throughout)
[18:50] <nrstott> what's your plan for Dojo in the future btw... what's its place in the brave new world of sproutcore, cappuccino, and gwt
[18:50] <deanlandolt_> it'd be nice if that jsgi adapter could be also be used as a jack handler
[18:50] <kriszyp> heh
[18:51] <kriszyp> I think Dojo is already pretty well-positioned for rich client side apps, is there something you think it is missing?
[18:51] <deanlandolt_> nrstott: dion almaer thinks dojo should merge with closure
[18:51] <nrstott> being commonjs ;0
[18:51] <kriszyp> ah, I see
[18:52] <kriszyp> there has been discussion about how to do module loading in dojo 2.0, and commonjs has been part of that
[18:52] <kriszyp> I haven't really been that much a part of that discussion though
[18:52] <nrstott> i haven't seriously looked into dojo in about a year now, don't know what advancements have been made in that time
[18:53] <kriszyp> and the gap between how you load modules in the browser vs the server seems so wide, I just haven't been that interested in bridging it, but I am sure it could be done in dojo
[18:53] <kriszyp> and there are surprisingly few modules that are actually applicable to both sides
[18:54] <deanlandolt_> nrstott: the easiest way to break jack's narwhal dep may be to extract and package up some of the narwhal (like hash)
[18:55] <nrstott> how much do the node guys care about jsgi and commonjs?
[18:55] <deanlandolt_> nrstott: they don't seem to care much about jsgi
[18:56] <deanlandolt_> but they're involved invested at least by way of modules, so it's something
[18:56] <nrstott> why don't they care about jsgi?
[18:56] <nrstott> any reason?
[18:56] <deanlandolt_> jsgi kinda clashes with their overall philosophy
[18:56] <nrstott> how so?
[18:56] <deanlandolt_> it's easiest form is syncronous
[18:57] <nrstott> well that's true about anything ;0
[18:57] <deanlandolt_> but with the stuff kriszyp's suggested for jsgi async it's surprisingly easy to convert current middleware to be async-aware...at that point node folks may start caring
[18:57] <nrstott> yeah Ive been following the threads a bit on the mailing list
[18:58] <deanlandolt_> nrstott: true...but the async response form is pretty simple now
[18:58] <nrstott> async middleware seems odd to me... how do you async set a header
[18:58] <nrstott> it seems like in a response things have to be done in order
[18:58] <deanlandolt_> with kris's suggestion of having a lower-level api for evented interactions it may bring node into the fold
[18:58] <deanlandolt_> nrstott: you pass back a promise
[18:59] <nrstott> I wish we'd call promises IOUs :)
[18:59] <deanlandolt_> heh
[18:59] <deanlandolt_> but it's all pretty simple
[18:59] <nrstott> promises dont sseem like they should be taking so much discussion
[18:59] <nrstott> they are pretty simple
[18:59] <deanlandolt_> and you just use when (or whenPreservingType, actually)
[19:00] <deanlandolt_> yeah, but different people have different notions of them
[19:00] <nrstott> in a .NET framework im a committer to, we call them Futures
[19:00] <nrstott> and no one argued at alla bout how to implement them or about naming
[19:00] <nrstott> we jsut did them and it worked fine...
[19:02] <nrstott> deanlandolt_, do you have a link offhand to the current discussion / wiki page about the async issues?
[19:02] <deanlandolt_> sure...there are three threads...
[19:03] <deanlandolt_> first, kriszyp's recent proposal: [CommonJS] HTTP Event Interface + JSGI (was ... JSGI Level 0/A Draft 2 ... progressive async streaming)
[19:03] <nrstott> you_owe_me('identifier').then_i_do(function() {})
[19:03] <nrstott> seems that simple to me ;0
[19:03] <deanlandolt_> yeah, i agree
[19:04] <deanlandolt_> or when(you_owe_me, function())...
[19:04] <nrstott> i prefer the fluent interface
[19:04] <nrstott> but either would work
[19:04] <deanlandolt_> the big async thread: [CommonJS] JSGI Level 0/A Draft 2 Proposal on the wiki... (progressive async streaming)
[19:04] <deanlandolt_> well, the different between the two is that when works even if what comes back is sync
[19:05] <deanlandolt_> and if you use whenPreservingType it will return sync as well
[19:05] <deanlandolt_> (instead of returning a promise)
[19:05] <nrstott> why would fluent not work when you get it synch?
[19:05] <deanlandolt_> possiblePromise.then doesn't exist if possiblePromise isn't actually a promise
[19:06] <deanlandolt_> unless i'm misunderstanding wha tyou mean by fluent
[19:06] <nrstott> so the issue is the loader or whatever wuld always have to return a promise?
[19:06] <deanlandolt_> yeah...and some code wouldn't want to do that...
[19:06] <nrstott> itd be super easy to wrap the sync stuff in JS with the when, or you_owe_me fn is called and receives a sync result
[19:07] <deanlandolt_> but we can write "promise-aware" middleware that just does a whenPreservingType(response, function()...) and that's all we need to do sync and async
[19:07] <deanlandolt_> yeah, it's all already part of the promise api in narwhal
[19:07] <nrstott> ok
[19:07] <deanlandolt_> it'd be nice if node adopted an identical api (though, it looks like they're moving away from promises to deferreds anyway)
[19:08] <nrstott> ok what quibble to they draw between the term promise and deferred (they both mean the same thing)
[19:09] <nrstott> promises, deferreds, and futures are the exact same thing in my head...
[19:09] <deanlandolt_> they're slightly differnet i guess
[19:09] <deanlandolt_> from how they were describing deferreds they sounded an awful lot like narwhal's promises
[19:09] <deanlandolt_> (but they have a /different/ notion of promises)
[19:09] <nrstott> *sigh*
[19:09] <deanlandolt_> that's what i meant by promises mean different things to different poeple ;)
[19:09] <nrstott> who has the bigger user community currently
[19:09] <nrstott> lets just let them win ;0
[19:10] <deanlandolt_> heh
[19:10] <nrstott> do the node guys have a channel on freenode?
[19:10] <deanlandolt_> #node.js
[19:11] <nrstott> looking at KrisZyps thread, it doesn't seem like anyone responded to it...
[19:13] <deanlandolt_> no, not yet
[19:13] <deanlandolt_> it was from this morn...i haven't had the time to respond
[19:13] <nrstott> hm, it was only 3 hours ago
[19:13] <nrstott> i see :)
[19:13] <deanlandolt_> but it seems like the perfect solution
[19:13] <nrstott> i had not looked at the date
[19:13] <nrstott> yeah it looks great
[19:13] <deanlandolt_> but i'm not the one clamoring for more a low-level async api
[19:14] <deanlandolt_> that said, i think it'd be really cool if this became the model for a standard low-level tcp interface as well
[19:14] <deanlandolt_> we should be able to write low level services (like node's irc server) that work interoperably...at least, that'd be a pretty cool goal
[19:18] <kriszyp> arg, does require("../module") not work in node?
[19:18] <nrstott> it appers that Node's 'require' can import into the global namespace
[19:19] <kriszyp> what is their irc channel?
[19:19] <nrstott> node.js
[19:19] <nrstott> their requires is way different
[19:19] <nrstott> im looking at some example usages...
[19:19] <nrstott> they do shit like require.paths.unshift('lib')
[19:19] <nrstott> that affects future requires after it..
[19:19] <nrstott> there may be much more of a gap here than id imagined
[19:20] <kriszyp> yeah, thats what I am doing
[19:20] <kriszyp> require.paths.push/unshift is pretty standard
[19:20] <kriszyp> and it works fine in node, but it looks ../ doesn't work
[19:21] <deanlandolt_> kriszyp: you can nag isaacs about it here as well (i believe he implemented node's require)
[19:26] <isaacs> deanlandolt_: actually, ryah_away did it originally.
[19:26] <isaacs> i'm just messing with it
[19:26] <deanlandolt_> oh, cool
[19:27] <nrstott> isaacs, so Nodes require imports into the global namespace?
[19:27] <isaacs> nrstott: no, it returns an exports commonjs-stylie
[19:28] <nrstott> ok
[19:28] <isaacs> you CAN do that if you use process.mixin to put the expots into the process obj
[19:28] <isaacs> but that's bad form, imo
[19:28] <nrstott> ok, well http://github.com/visionmedia/express seems to be importing the DSL into the module via requires
[19:28] <nrstott> unless configure() does something im not aware of
[19:29] <isaacs> once upon a time, there was an "import" that did that
[19:29] <nrstott> well his example just uses "require"
[19:29] <isaacs> hm... yeah, weird
[19:29] <isaacs> wonder what version of nodejs he's using
[19:30] <kriszyp> woot, got hello-world JSGI app running on Node
[19:30] <nrstott> nice1 kris
[19:30] <nrstott> now get the Bogart hello world running on it and you're my hero ;0
[19:30] <isaacs> kriszyp: whereat?
[19:31] <isaacs> also, is it async?
[19:31] <kriszyp> well, I haven't uploaded it yet
[19:31] <kriszyp> and yes it is async
[19:31] <isaacs> very interesitng
[19:31] <deanlandolt_> that's awesome
[19:31] <kriszyp> well, my hello-world wasn't, but the adapter is
[19:31] <kriszyp> I'll try an async hello world in a bit
[19:34] <isaacs> kriszyp: push it to github!!
[19:34] <isaacs> asap!!
[19:34] <isaacs> zomg!
[19:37] <isaacs> is there a way in es5 lingo to define a setter on a function param?
[19:39] <nrstott> on a function param? what exactly does that mean?
[19:39] <isaacs> like...
[19:39] <isaacs> function foo (bar) { }
[19:39] <nrstott> a setter on bar?
[19:40] <isaacs> inside "foo", if I do "bar = 1", i want to fire the setter.
[19:40] <deanlandolt_> a setter on arguments[0]?
[19:40] <nrstott> if bar is already a proeprty, sure...
[19:40] <nrstott> i dont really understand what application there would be other than that
[19:40] <isaacs> nrstott: we're talking about setExports, and implementing as a setter on module.exports.
[19:40] <isaacs> it'd be interesting to implement as a setter on "exports" itself.
[19:41] <nrstott> Object.defineProperty(exports, { ... } )
[19:41] <isaacs> then you could just do "exports = MyThing"
[19:41] <nrstott> what's wrong with that?
[19:41] <nrstott> you don't have the exports var availalbe when you want to assign it?
[19:41] <isaacs> nrstott: that would define a setter for a member of exports.
[19:41] <isaacs> not for exports itself.
[19:41] <nrstott> right...
[19:41] <nrstott> so Object.defineProperty(global, "exports", ...
[19:42] <isaacs> nrstott: doesn't work with async require and child modules, though
[19:42] <isaacs> if foo.js does require("bar") thne "bar" will steal the setter
[19:42] <Dantman> with(){} to the rescue!
[19:42] <isaacs> Dantman: heresy!
[19:43] * Dantman wishes for some sort of dynamic bind
[19:43] <isaacs> true, though, you could do with ({exports: exports}){ and then define a setter/getter on the object you'er passing to with()
[19:44] <Dantman> var {bar as bar} = require('foo'); // local scope bar will always be an alias for fooExports.bar, so if fooExports.bar is changed, then bar will be changed to.
[19:45] <isaacs> Dantman: we're not all using spidermonkey :P
[19:45] <ashb> and evne those of who are that work wotk, its invalid :)
[19:46] <isaacs> oh, that looked like destructuring, sorry, in a mtg, not paying full attention
[19:47] <ashb> it is, its just done wrong
[19:47] <ashb> var { bar: bar} = require('foo')
[19:47] <ashb> but i dont think it works properly in all cases in spidermonkey yet
[19:47] <isaacs> i see
[19:47] <isaacs> anyway....
[19:48] <isaacs> i could wrap the module code in with(module), but that'll also create "id" and "uri" variables
[19:48] <Dantman> Abused destructuring sysntax, my point was on the alias though
[19:48] <ashb> and give you a ... 4x performance hit too boot
[19:48] <nrstott> with() is my favoriet javascript feature.
[19:48] <isaacs> ashb: srsly!
[19:48] <isaacs> ok, so with(){} is out
[19:49] <nrstott> its a shame that it gets hated on so much
[19:49] <ashb> i think so
[19:49] <ashb> somone did some testing and it was *slow*
[19:49] <isaacs> it wasn't always so slow.
[19:49] <nrstott> its slow because it prevents a lot of optimizations
[19:49] * Dantman needs to rethink his new color scheme
[19:49] * Dantman can barely see the names of people typing
[19:49] <isaacs> it's just that (function(){ }) was more common, and got more optimization love
[19:50] <ashb> i dont see why with is that different to just looking things up in the global var
[19:50] <Dantman> Nah, the real issue is that with() {} makes variable names invisible
[19:50] <nrstott> it's because if youre inside of a with() then how does it optimize when you do something like a = b
[19:50] <nrstott> it has to check everytime to see if the with(foo) has an a on it
[19:50] <nrstott> because an a may be added before the with is completed
[19:50] <ashb> nrstott: hos does it do it for hte global object?
[19:51] <Dantman> Global object is the great fallback. If you can't see it locally, you just skip all the local scopes and look at the global. As I understand it.
[19:51] <kriszyp> so node is complete fail on circular deps with require
[19:51] <Dantman> But with() makes it so you must look at those local scopes, voiding the optimization of skipping them
[19:52] <nrstott> i think that's right Dantman
[19:52] <ashb> hmmmm ture. i'm sure it could be optimized so its not better
[19:52] <nrstott> still. some withs aren't that bad
[19:52] <kriszyp> isaacs: is there any hope for circular deps on node?
[19:52] <ashb> but keeping track of a simple counter when you put anything on with
[19:52] <nrstott> im getting awesome performance from Bogart and every EJS template that I render has a with() around it
[19:52] <isaacs> kriszyp: it works, yeah
[19:52] <Dantman> Mhmm... I especially hate the way Crockford calls it "bad"
[19:52] <ashb> and if oyu dont, preoptimize
[19:53] <Dantman> He demonstrates a way to use it in the wrong way, then writes it off as evil because of that.
[19:53] <ashb> i can't find the speed tests taht someone did, its really hard to google for
[19:53] <isaacs> kriszyp: with the setExports proposal, it's even securable
[19:53] <kriszyp> it is crashing node for me
[19:53] <Dantman> I still like that alias idea
[19:53] <kriszyp> I can switch to the node room though...
[19:54] <Dantman> Perhaps an alias ...; keyword
[19:59] * Dantman also entertains the idea of a .local syntax;
[20:01] <Dantman> Hmm... though var foo = { (keyvar): value }; would be nicer.
[20:02] <ashb> Dantman: what are you on about?
[20:03] <kriskowal> kriszyp, it's ideological heresy, but i got narwhal's module loader to run on node. at some point i'll get require.async working in narwhal's loader with node's async fs ops.
[20:03] <Dantman> var keyname = "foo"; var o = { (keyname): "bar" }; print(uneval(o)); // ({ 'foo': "bar" })
[20:04] <kriskowal> whenever i get time, i'm trying to build a narwhal executable for node that does module injection and bootstraps
[20:04] <kriszyp> kriskowal: woot!
[20:04] <kriszyp> I suppose you saw that I just got JSGI working on Node
[20:04] <kriskowal> it needs a lot of work for the file system and io modules though.
[20:04] <kriszyp> running it fail on circular deps for require in node though
[20:04] <Dantman> As opposed to: var keyname = "foo"; var o = {}; o[keyname] = "bar";
[20:04] <kriskowal> oh, jsgi hello world, that's awesome.
[20:04] <kriszyp> have you seen that?
[20:05] <kriskowal> no. i only cursorially reviewed their loader.
[20:05] <kriszyp> so I am trying to remove all circular deps in my code, painful
[20:05] <kriskowal> i'm not sure how async works, but i doubt that it does since i didn't see any static analysis
[20:06] <kriskowal> well, if you don't mind writing c++, i could use some help creating "file-engine", "io-engine", and "binary-engine" modules on node.
[20:06] <kriszyp> I am just using the standard sync require though
[20:06] <kriszyp> oh man, its been a long time...
[20:06] <kriskowal> yeah, same here. strange weekend.
[20:07] <kriskowal> and the code may as well have under construction signs posted everywhere.
[20:07] <kriskowal> but it's good stuff. just needs a lot of work, and will no doubt get a lot of work what with the amount of attention it's getting and the value it adds.
[20:08] <kriszyp> yeah, I am surprised how much attention it is getting, but it is a cool project
[20:09] <ondras_> hmmh
[20:09] * ondras_ just reported a bug in ff 3.5x
[20:09] <ondras_> and they replied that it seems not present in 3.6
[20:10] <ondras_> do some of you guys have 3.6 avail?
[20:17] <ondras_> never mind, tested myself
[20:20] <kriszyp> so kriskowal, are you organizing this by having an engines/node in narwhal with node specific stuff?
[20:27] <kriszyp> arg, base64 has engine-specific deps
[20:27] <kriszyp> I guess that was for narwhal
[20:49] <nrstott> I really hate the idea of having two similar and competing frameworks in an already young server-side JS world
[20:50] <kriskowal> doesn't bother me particularly.
[20:51] <kriskowal> what is commonjs but a bunch of "competing" frameworks that are seeking to become interoperable across their non-differentiating components.
[20:51] <nrstott> interoperable essentially means non-competing
[20:51] <kriskowal> but only for non-differentiating components
[20:52] <nrstott> i don't really see narwhal and GPSEE for instance as being "competing"
[20:52] <kriskowal> perhaps not.
[20:53] <kriskowal> but gpsee and flusspferd?
[20:53] <nrstott> i dont know anything about flusspferd
[20:53] <ashb> gpsee is what wes is using in house
[20:53] <ashb> and just happens to be loosly following/shaping commonjs
[20:53] <kriskowal> in any case, diversity helps the ecosystem
[20:54] <ashb> flusspferd is either a JS embedding for C++ projects or as a comonnjs platform
[20:54] <nrstott> I don't know about that kriskowal. Look at the diversity in the Java world. It seems to have created more confusion than anything else.
[20:54] <nrstott> there are so many frameworks that do essentially the same thing
[20:54] <kriskowal> ah, well, the question is philosophical and not one that we have a great deal of control over.
[20:55] <ashb> you are alwasy going to get people reinventing a slightly 'rounder' wheel
[20:55] <kriskowal> everyone has to cut their teeth reinventing the wheel anyway
[20:55] <nrstott> I prefer the Ruby world, though there are competing implementations of rather similar things there too ;0
[20:55] <nrstott> it's not as bad as java though
[21:01] <nrstott> overall it doesn't really matter for something as small as Bogart / Sinatra like frameworks
[21:01] <Dantman> Quercus!
[21:01] <nrstott> but if it were a more full-stack MVCish framewrok like Rails, i could see a problem
[21:02] <nrstott> I think Rails and Merb merging was great for Ruby. The two competing would've sucked
[21:02] * Dantman starts getting crazy ideas about connecting php and javascript by running both under Java.
[21:04] <nrstott> Dantman, what about a webserver that allows rack and jack middleware ;0
[21:05] <Dantman> ruby + js?
[21:08] <nrstott> yeah
[21:08] <nrstott> already got JRuby and Rhino
[21:09] <Dantman> Meh, I have no reason to go into ruby if I'm already in js
[21:09] <nrstott> but you do PHP?
[21:09] <Dantman> ^_^ But executing JS from PHP means we can integrate server-side JS into existing php systems like MediaWiki
[21:10] <Dantman> Even better than lua integration
[21:12] <Dantman> Errr.... crap, I'm beeing hooked.... Reading a blog entry is making me want to jump into Quercus and start tweaking parts of the MediaWiki core to be optimized running under it making speed jump.
[21:15] <MisterN> nrstott: do not fail to look at flusspferd, which is the _best_* commonjs platform. (*) i'm absolutely unbiased
[21:15] <nrstott> Mister_N, noted ^^
[21:16] <Dantman> Oooh, fun... php already has an api built in for interaction with Java... I wonder if Quercus abused that nicely in implementation.
[21:16] <Dantman> ^_^ If so, things could get real fun.
[21:18] <nrstott> MisterN, if you make bogart run on flusspferd, I promise I'll be super interested in it :)
[21:18] <MisterN> nrstott: what is bogart? :D
[21:18] <nrstott> http://github.com/nrstott/bogart
[21:19] <ashb> nrstott: your git config is setup wrong
[21:19] <ashb> the email isn't the same as your github account
[21:20] <ashb> Bogart.Version = "0.0.2";
[21:20] <ashb> shouldn't that be VERSION too?
[21:20] <nrstott> what's VERSION in all caps about?
[21:20] <ashb> its how constatns are usually defined
[21:21] <nrstott> well, as we know, there aren't really constants in JavaScript ;0
[21:21] <ashb> there are in spidermonkey ^_^
[21:21] <nrstott> is this some convention that I'm not aware of about declaring VERSION in all caps
[21:21] <ashb> not version specifically
[21:21] <nrstott> well yeah I could Object.defineProperty it with oly a getter
[21:21] <MisterN> there's "const"
[21:21] <MisterN> const x = 4;
[21:22] <MisterN> maybe v8 doesn't support it, tho :/
[21:22] <ashb> MisterN: doesn't work for properties of an object tho
[21:22] <MisterN> ashb: oh
[21:22] <nrstott> ashb, my git email is set to nathan.stott@whiteboard-it.com according to my cmd line here ;0
[21:22] <nrstott> where are you seeing it as something different?
[21:23] <ashb> nrstott: http://github.com/nrstott/bogart/blob/master/lib/bogart.js
[21:23] <ashb> the 'Nathan' (athor) doesn't linke to your github account
[21:23] <ashb> which usally means its different
[21:23] <nrstott> ah
[21:23] <nrstott> ill check on that
[21:24] <nrstott> thanks for pointing it out
[21:25] <ashb> nrstott: bogat is a jsgi app?
[21:25] <nrstott> indeed
[21:25] <ashb> or presents a JSGI interface rather?
[21:28] <ashb> hmmm how are keywords different to categories
[21:32] <nrstott> ?
[21:32] <nrstott> keywords, categories?
[21:32] <ashb> http://wiki.commonjs.org/wiki/Packages/0.1
[21:48] <MisterN> could somebody please tell mochabot not to spam everybody aftert a netsplit?

 

 

Logs by date :