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

2010-01-12:

[0:05] <cpojer> tlrobinson: are you going for a michael corleone look? ;)
[0:06] <tlrobinson> cpojer: hah sure
[4:53] <gozala> Hi folks! I was wondering is there was something stopping from ratifying Promise API proposal?
[5:00] <kriskowal> gozala probably only that very few of us know what it does
[5:01] <gozala> ok I'll try to refresh proposal on mailing list
[5:02] <gozala> I was also thinking about async io / filesystem, and guess it can be promise based
[5:03] <gozala> I meant refresh discussion
[5:03] <keeto> why?
[5:03] <gozala> @keeto why what ?
[5:04] <gozala> why promise based ?
[5:04] <gozala> or ...?
[5:04] <keeto> oh, I didn't see the async part there.
[5:04] <keeto> my bad.
[5:04] <gozala> np :)
[5:05] <SubtleGradient> is there an existing common pattern for promise-based scripting in js?
[5:06] <SubtleGradient> gozala: ??
[5:07] <gozala> there are several drived by different frameworks
[5:07] <gozala> I think they are mentioned along with propoal itself
[5:07] <gozala> *proposal
[5:08] <gozala> http://wiki.commonjs.org/wiki/Promises
[5:08] <SubtleGradient> thx
[5:08] <gozala> you're welcome
[5:08] <SubtleGradient> i don't know if i've ever known of anyone using promises before
[5:08] <SubtleGradient> or maybe they call it something else
[5:10] <gozala> honestly I was kind of trying to avoid it for a while in favor of simple observer impl.
[5:10] <gozala> But I kind of started liking it.
[5:10] <SubtleGradient> maybe an observer/events system with promise sugar?
[5:11] <SubtleGradient> i'll read the rest before I completely eat my foot ;)
[5:11] <gozala> ;)
[5:15] <kriskowal> SubtleGradient, the current promise proposal is very minimal
[5:15] <SubtleGradient> why does this need to be in CommonJS?
[5:15] <kriskowal> it is possible to implement promises on top of an observer system
[5:16] <kriskowal> because it's a good basis for all async api's
[5:16] <SubtleGradient> what's the goal of CommonJS?
[5:17] <SubtleGradient> to unify the common stuff across all js implementations I guess
[5:17] <kriskowal> yes
[5:17] <SubtleGradient> I like the idea of unifying the way all async stuff is done
[5:17] <kriskowal> to make it possible to write interoperable applications that can run on a variety of embeddings
[5:17] <SubtleGradient> I'm not completely sold on the api asis, but I like the unification idea
[5:18] <SubtleGradient> how is async stuff handled in other languages like Python and Java?
[5:18] <kriskowal> it's very difficult to make an api that tastes good to everyone; we all have our preconceptions
[5:18] <SubtleGradient> I don't remember any common way to do async in Ruby
[5:19] <SubtleGradient> the idea is to make it feel the most JavaScripty I guess
[5:19] <SubtleGradient> js shouldn't try to be ruby or python or java or smalltalk, etc?
[5:20] <kriskowal> that means different things to different people
[5:20] <SubtleGradient> exactly
[5:20] <SubtleGradient> MooTools works very very hard making all our apis very JavaScripty
[5:20] <kriskowal> so, promises come from a system called E
[5:21] <SubtleGradient> Prototype explicitly tries to be Ruby-like. MochiKit was intentionally very Python-like. jQuery is? jQuery-like
[5:21] <SubtleGradient> I'll read up on it.
[5:21] <kriskowal> it's a programming language any function call can be deferred, and any value can be a promise
[5:21] <SubtleGradient> if it's good I might just bring it into MooTools ;)
[5:21] <SubtleGradient> neat
[5:22] <kriskowal> so, there are about four generations of asynchronous API styles
[5:22] <SubtleGradient> I'm familiar with callbacks & events/observers
[5:22] <kriskowal> callbacks, continuation passing style, deferreds, then promises
[5:22] <SubtleGradient> with various apis
[5:23] <SubtleGradient> Ruby's continuations are interesting magic
[5:23] <kriskowal> so, deferreds are a kind of observable object
[5:24] <kriskowal> they emit success and failure signals
[5:24] <SubtleGradient> can you imagine any use for an event object for promises? or for bubbling?
[5:24] <kriskowal> the distinction between a deferred and a regular observable is that only one event can be emitted by a deferred, ever.
[5:24] <kriskowal> either success or failure.
[5:24] <SubtleGradient> gotcha
[5:25] <kriskowal> which makes it resemble a function's return value, just?later
[5:25] <kriskowal> the function either throws or returns, which map to emitting error and ok events
[5:25] <SubtleGradient> that makes good sense. object, fn, args, result
[5:26] <kriskowal> and after that event has been emitted, anyone who observes the deferred must be immediately (or in the next event loop "turn") be notified of the already known state
[5:26] <SubtleGradient> MooTools currently does that for the domready event
[5:27] <kriskowal> right, which makes domready, or any other "state", an ideal candidate for a promise
[5:27] <SubtleGradient> if it has already fired once then and new observers fire immediately when added
[5:27] <SubtleGradient> I was thinking about doing something separate for States
[5:27] <SubtleGradient> in mootools
[5:27] <SubtleGradient> but that wouldn't make sense for this
[5:27] <kriskowal> so the difference between deferreds and promises is very small?
[5:28] <SubtleGradient> learning I haz it
[5:28] <kriskowal> ("state" is perhaps not the best way to describe it)
[5:28] <SubtleGradient> i think I get it now though
[5:28] <kriskowal> (a one-time boolean switch state that partitions all time into a before and after)
[5:28] <SubtleGradient> just not used very often
[5:28] <SubtleGradient> at least in my experience
[5:28] <kriskowal> so promises are subtly different than deferreds
[5:29] <SubtleGradient> what would promises be used for then?
[5:29] <kriskowal> in promise systems, the ability to observe the promise and the ability to resolve it are separated
[5:29] <SubtleGradient> IO would need more than just hard returns
[5:30] <kriskowal> Q.defer() would return something that contains on one hand the observable "promise", and the other the "resolver"
[5:30] <kriskowal> so, if you want to defer, you would return the promise and keep the resolver to yourself.
[5:30] <SubtleGradient> might make a good Function.prototype.method
[5:30] <kriskowal> maybe, but that gets complicated.
[5:31] <kriskowal> i've been meaning to give that the thought it needs.
[5:31] <SubtleGradient> ya
[5:31] <kriskowal> like, f.async(1, 2, 3)
[5:31] <SubtleGradient> it'd have to be similar to bind
[5:31] <kriskowal> would return a promise
[5:32] <SubtleGradient> fn.bind(obj,arg1,2,3); fn.async(obj,arg1,2,3).then(foo).then(bar);
[5:32] <kriskowal> the trouble is in trust though. promises are deferreds + securability.
[5:32] <kriskowal> so, .then is an interesting function.
[5:33] <kriskowal> but, i see you've mostly figured it out.
[5:33] <SubtleGradient> i've thought a lot about similar things
[5:33] <kriskowal> yeah
[5:33] <SubtleGradient> e.g. bindLater
[5:33] <SubtleGradient> and String.prototype.bind
[5:33] <SubtleGradient> and Array.prototype.call, apply, bind, etc?
[5:34] <kriskowal> from the security point of view, the methods of an object you've been given are not necessarily trustworthy
[5:35] <kriskowal> if an object is suspect, the approach is to use a "when" function, analogous to "then"
[5:35] <SubtleGradient> ya, i can see that
[5:35] <kriskowal> return Q.when(promise, callback, errback)
[5:35] <SubtleGradient> but it could complicate the code considerably
[5:35] <kriskowal> Q.when takes a promise and returns a different promise.
[5:35] <SubtleGradient> now do 2 or 5 whens
[5:35] <kriskowal> not really.
[5:35] <kriskowal> it just chains differently.
[5:36] <SubtleGradient> ya, ok that could work
[5:36] <SubtleGradient> since when is trusted then its result would be
[5:36] <SubtleGradient> the only thing you get from your potentially untrusted promise is the pass/fail
[5:36] <SubtleGradient> the when would then handle its own then method
[5:36] <SubtleGradient> got it
[5:36] <kriskowal> anyhow, i've been learning all this through occasional conversations with the google caja team.
[5:37] <kriskowal> markm has a brilliant thesis on the topic of object-capabilities, event-loops, and promises.
[5:38] <SubtleGradient> toy I was playing with a while back: http://gist.github.com/261116
[5:38] <kriskowal> mostly in his E language, which interestingly enough, was named by doug crockford when they worked together at a previous startup
[5:38] <SubtleGradient> binding with property access
[5:39] <SubtleGradient> wow, another terrible name from Doug. ^_^
[5:39] <kriskowal> so, i expect that promises will be accused of not being "javascripty", but i think that should be forgiven. "better" should trump "familiar"
[5:39] <SubtleGradient> iJoke ofc. Doug is a legend
[5:39] <SubtleGradient> so long as it doesn't try to be something else I think it'll be ok
[5:40] <SubtleGradient> JSON.stringify may be one of the most horrible things I've ever seen. But I digress
[5:40] <kriskowal> yeah. thankfully there are sane alternatives
[5:40] <SubtleGradient> it'd be perfectly fine in Ruby
[5:41] <kriskowal> i'm pushing for encode and decode to become more standard names for that kind of thing.
[5:41] <kriskowal> it's the same story in python; they use loads and dumps in a couple places.
[5:41] <SubtleGradient> I think the biggest thing the promises proposal needs is some more/better examples of what it's good for
[5:41] <kriskowal> i think it's incomplete.
[5:41] <SubtleGradient> imho methods must be verbs
[5:41] <kriskowal> but not so incomplete i wouldn't show an affirmative hand on it.
[5:42] <kriskowal> (what was the exception to the rule?)
[5:42] <kriskowal> i'm not following what string.bind is for in your gist.
[5:42] <SubtleGradient> which rule?
[5:42] <SubtleGradient> ah
[5:42] <kriskowal> that methods should be verbs.
[5:42] <SubtleGradient> oh, different conversation
[5:42] <kriskowal> oh, oh.
[5:43] <SubtleGradient> the gist allows you to do `"fn".bind(obj, arg)` instead of `obj.fn.bind(obj, arg)`
[5:43] <SubtleGradient> which is great when the method doesn't exist yet
[5:43] <kriskowal> oh, i see.
[5:43] <kriskowal> probably a good place to put a different verb.
[5:44] <SubtleGradient> or when "obj" is something really crazy long and you don't want the extra scope resolution and wetness
[5:44] <kriskowal> i have a similar function in chiron for late binding methods
[5:44] <SubtleGradient> chiron?
[5:44] <kriskowal> you might enjoy a read of http://github.com/280north/narwhal/blob/master/lib/events.js
[5:44] <SubtleGradient> nice. I'll read that
[5:45] <SubtleGradient> i used bind since it does essentially what fn.bind does
[5:45] <kriskowal> the intent is to make API glue for various event system approaches
[5:46] <kriskowal> i could buy it.
[5:47] <kriskowal> "x".bind(f)(1) --- f.x(1)
[5:47] <SubtleGradient> ya, that should work
[5:47] * kriskowal squints
[5:47] <SubtleGradient> mostly useful for chaining fx as in that one example
[5:48] <SubtleGradient> see ~#30 of usage.js
[5:48] <SubtleGradient> pass is the same as bind except it doesn't set the thisObject
[5:49] <kriskowal> are you familiar with the effort to add variadic syntax in es-harmony?
[5:50] <kriskowal> x(1,2,3) --- x.apply(undefined, [1,2,3]) --- x(...[1,2,3])
[5:50] <SubtleGradient> adding syntax to JS is just annoying since I'll never be able to use it
[5:50] <kriskowal> ah, well. not in a browser this decade, sure.
[5:50] <SubtleGradient> i prefer to focus on reality, or creating things that "actually work" in the "real world"
[5:50] <kriskowal> but "it's gonna be the future soon"
[5:50] <SubtleGradient> and by "real world" i mean the world where people pay me
[5:51] <SubtleGradient> wake me when IE6 supports it ;)
[5:51] <kriskowal> like, today.
[5:51] <kriskowal> or, ten years ago as the case may be.
[5:51] <kriskowal> in any case, we're not hampered like that in server side situations.
[5:51] <SubtleGradient> I'm just glad I can finally use try/catch!
[5:51] <kriskowal> we can use modern js features on servers
[5:52] <SubtleGradient> well, my goal is to learn a univeral subset of JS
[5:52] <SubtleGradient> ^universal
[5:52] <SubtleGradient> and write code that works everywhere always
[5:52] <kriskowal> well, then there's commonjs; trying to expand the realm of a universal subset.
[5:52] <SubtleGradient> sure, I'll use new methods and stuff if they exist and are better, but not new syntax
[5:53] <SubtleGradient> that's why CommonJS interests me
[5:53] <kriskowal> i think we can separate our notions of what we're doing to make yesterday easier from what we're doing to make tomorrow more powerful
[5:53] <SubtleGradient> I dream of writing a single script that works on all browsers and on the CLI and in ssjs on JSscript and node.js and rhino, etc?
[5:53] <kriskowal> i've got a couple.
[5:54] <SubtleGradient> i'm not against anyone else using the new cool stuff ofc.
[5:54] <SubtleGradient> we need to keep pushing forward. but right now I want to focus on stuff I can do now
[5:54] <kriskowal> i wrote chiron for browsers; in its original incarnation, it was a module system and a bunch of modules, for browsers
[5:55] <kriskowal> it uses sync xhr though, which is great for debugging, but has performance and scalability problems.
[5:55] <SubtleGradient> I am one of the 4 board members of MooTools too, so I want to move that project forward into all these platforms
[5:55] <kriskowal> aye.
[5:55] <SubtleGradient> MooTools is already being used on the serverside and to script desktop apps and stuff, but it could be smoother
[5:55] <kriskowal> i spoke with one of your fellows a month ago
[5:55] <SubtleGradient> we are many
[5:56] <SubtleGradient> 2009 was a big year for us.
[5:56] <kriskowal> christoph pojer
[5:56] <SubtleGradient> he's very good.
[5:57] <kriskowal> the essence of our conversation was that, since you already use a compilation step to prepare scripts for production, you could have your code written in commonjs modules and then bundle them for client-side consumption
[5:57] <kriskowal> it's pretty simple to wrap a script in register("id", function (require, exports, module) {?})
[5:57] <SubtleGradient> yeah, when you get into the details there are some sticking points
[5:58] <kriskowal> nothing unresolvable though.
[5:58] <SubtleGradient> there are thresholds though
[5:58] <kriskowal> i did one such system with django/python a week or so ago
[5:58] <SubtleGradient> MooTools was always designed to be an extension to your environment
[5:58] <SubtleGradient> so it expects everything to be in scope
[5:59] <kriskowal> that works for very fundamental things, if you don't mind not playing well with others
[5:59] <kriskowal> and still should work, with very early buy-in. but applications should be written by composing reusable modules.
[6:00] <SubtleGradient> on the client-side you don't want to load too much code. so nobody in their right mind would ever want Prototype and Mootools on the same page for instance
[6:00] <kriskowal> effectively, i think mootools has grown beyond that; you now have people doing manual dependency resolution to package mootools for their projects
[6:00] <SubtleGradient> yeah, things are changing
[6:00] <kriskowal> right, but many people in their right minds would love to be able to write applications that are "platform" agnostic
[6:01] <SubtleGradient> we just need to decide what our core principals are going forward into 3.0 and beyond
[6:01] <kriskowal> well, there's an area of compromise.
[6:01] <SubtleGradient> right
[6:01] <SubtleGradient> and until now it hasn't been worth it to support much of it
[6:01] <kriskowal> under a certain line, things can be presumed to exist globally, and beneath that, things are in modules.
[6:02] <SubtleGradient> but on the serverside the major fundamental rules for code are thrown out the window
[6:02] <kriskowal> for commonjs, that's basically es-5 under the hood and commonjs above
[6:02] <kriskowal> some of them, yeah
[6:02] <SubtleGradient> we've been discussing the best way to make mootools commonjs compatible
[6:02] <SubtleGradient> without requiring a build step on the client or server
[6:03] <kriskowal> (chiron 2 if your curious (a commonjs package) http://github.com/kriskowal/chiron/)
[6:03] <SubtleGradient> and being able to support sandboxed modules
[6:03] <SubtleGradient> very interested, thx
[6:03] <kriskowal> (chiron 1 if you're morbidly curious http://code.google.com/p/chironjs/)
[6:04] <SubtleGradient> kriskowal: you on twitter?
[6:04] <keeto> SubtleGradient: 3.0? :O
[6:04] <kriskowal> yes. same name.
[6:04] <SubtleGradient> keeto: gotta think ahead
[6:04] <keeto> 2016 ahead? :P
[6:04] <SubtleGradient> more like the end of the year
[6:04] <SubtleGradient> if not sooner
[6:04] <SubtleGradient> should be really hot on the heels of 2.0
[6:05] <SubtleGradient> might just be named 2.1 or something though
[6:05] <keeto> hear hear!
[6:05] <keeto> 2.0 will be awesome.
[6:05] <SubtleGradient> already is ;)
[6:05] <keeto> hah! right, right. :D
[6:06] <SubtleGradient> kriskowal: lol, I'm already following you on twitter ^_^
[6:06] <SubtleGradient> i thought your name looked familiar
[6:06] <kriskowal> yours?
[6:06] <SubtleGradient> SubtleGradient
[6:06] <SubtleGradient> ofc
[6:07] <kriskowal> ah, there you are
[6:07] <SubtleGradient> gotta love the Zelda music ^_^
[6:08] <kriskowal> i?didn't get much sleep this weekend
[6:08] <SubtleGradient> i know the feeling
[6:08] <kriskowal> the point of "decomposing" it was to sing around the office. we had parts 1 and 2 for the first verse, but needed more.
[6:09] <kriskowal> now we haz sheet music
[6:09] <SubtleGradient> where do you work? / what do you do
[6:09] <SubtleGradient> they need rock band Zelda!
[6:09] <SubtleGradient> and Mario ofc
[6:09] <kriskowal> company in pasadena, ca (near la). we do tcp acceleration.
[6:10] <kriskowal> (fastsoft)
[6:10] <SubtleGradient> wow, snore-tastic ;)
[6:10] <kriskowal> it's pretty exciting really
[6:10] <SubtleGradient> *nerd alert*
[6:10] <SubtleGradient> :D
[6:10] <SubtleGradient> iJoke ofc
[6:10] <kriskowal> little caltech startup, selling to the big bay area companies
[6:11] <SubtleGradient> I shouldn't talk. I just do client-side webdev for an agency
[6:11] <SubtleGradient> i've done some fun sites though
[6:12] <SubtleGradient> Java.com, JavaFX.com, USGA.org, tons of secret intranet stuff I can't talk about ;)
[6:12] <SubtleGradient> *cough visa*
[6:12] * SubtleGradient picks up all the names he dropped
[6:12] <kriskowal> hahah. yeah. but, hey, it's darn gratifying to see your work in front of real users.
[6:13] <SubtleGradient> it really is
[6:13] <SubtleGradient> I miss doing print design
[6:13] <SubtleGradient> WAY back in the day
[6:13] <SubtleGradient> I'm going to try and do some ssjs in ASP / .NET
[6:13] <SubtleGradient> since they're a .NET shop it's very easy to get ssjs working
[6:13] <SubtleGradient> but I'd love to do it in a more CommonJS sort of way
[6:14] <kriskowal> someone was talking about getting narwhal to run on asp earlier today.
[6:14] <SubtleGradient> that might have been me
[6:14] <kriskowal> ahh. i probably confused you.
[6:14] <SubtleGradient> i'm no lover of microsoft. But I love the people I work with, so I use what they tell me to use
[6:15] <kriskowal> in the race to inbox 0 on 6 hours of sleep.
[6:15] <SubtleGradient> i mostly care about client-side anyway
[6:15] <SubtleGradient> kriskowal: should we throw you a party when you get there?
[6:15] <SubtleGradient> only to receive an email about it ^_^
[6:15] <kriskowal> ouch
[6:16] <SubtleGradient> one thing I learned recently
[6:16] <SubtleGradient> protip: inbox zero != RSS 0 && twitter 0
[6:16] <kriskowal> i keep it empty, really. everyone's got their own process. i couldn't fathom reading/responding to email without the satisfaction of being done once in a while.
[6:17] <SubtleGradient> ya, i keep it at 0
[6:17] <SubtleGradient> but it's pretty easy where i work
[6:17] <kriskowal> yeah, i do all three. the trick is to have the full control loop.
[6:17] <SubtleGradient> i hear google employees spend 98.3% of their time reading email
[6:17] <kriskowal> by keeping them at 0, i know how much i can honestly subscribe to
[6:17] <SubtleGradient> i do the same.
[6:17] <SubtleGradient> i recently sumped all my rss
[6:17] <SubtleGradient> ^dumped
[6:18] <SubtleGradient> now I follow mostly js blogs only
[6:18] <kriskowal> ah, "rss bankruptcy". gotta love the term.
[6:18] <SubtleGradient> found some recently good ones from japan
[6:18] <SubtleGradient> google reader has translation built in!
[6:18] <kriskowal> oh, sweet
[6:18] <SubtleGradient> i'm dying to find all the hardcore non-english js hackers out there
[6:19] <isaacs> hey, kriskowal, you got a list with a bunch of package.json-style projects out there?
[6:19] <kriskowal> well, there's the narwhal catalog
[6:19] <kriskowal> if that's what you mean
[6:19] <isaacs> sure, that works
[6:19] <kriskowal> http://github.com/280north/narwhal/raw/master/catalog.json
[6:19] <kriskowal> or, newer schema http://github.com/280north/narwhal/raw/master/catalog-2.json
[6:20] <isaacs> yes, i must have the newest schema
[6:20] <SubtleGradient> anyone working on a packaging / dependency system for js like rubygems or easy_install?
[6:20] <kriskowal> it's not commonjs compliant yet. we ratified that when...yesterday?
[6:21] <kriskowal> SubtleGradient, yeah, that's what narwhal's tusk is.
[6:21] <SubtleGradient> ah, good to know
[6:21] <kriskowal> ashb is working on one too, i think.
[6:21] <SubtleGradient> now I won't have to build one myself :D
[6:21] <kriskowal> and michael o'brien
[6:21] <SubtleGradient> and PC support?
[6:22] <kriskowal> oh, windows?we need a volunteer.
[6:22] <isaacs> kriskowal: seems like there's a lot of data that's in narwhal's packages.json, but isn't in the project's package.json
[6:22] <SubtleGradient> i vote someone-that's-not-me implements it for windows
[6:22] <kriskowal> the package.json gets normalized.
[6:22] <isaacs> erm, catalog.json
[6:23] <isaacs> kriskowal: but, like, keywords and whatnot
[6:23] <kriskowal> can't say i know what you mean. all of that comes straight from package.json into catalog.json
[6:24] <isaacs> compare teh entry for creolejs
[6:24] <isaacs> with the package.json at "descriptorUrl": "http://github.com/kriskowal/creolejs/raw/master/package.json",
[6:24] <kriskowal> SubtleGradient, it's just a matter of getting someone to work out the kinks in the "file" module for windows. we just don't have someone keeping an eye on that. when i'm not getting paid, i don't use windows.
[6:25] <SubtleGradient> me neither
[6:25] <SubtleGradient> maybe I'll find a way to "need" it for work ;)
[10:52] <ashb> which module should expansion of ~foo/bar et al. live?
[10:57] <ashb> either fs-base.glob
[10:57] <ashb> or a separate glob module
[11:00] <MisterN> fs-base.glob only if commonjs specifies such an expansion
[11:00] <MisterN> otherwise, how about a fs-extra/glob module or something like that?
[11:00] <ashb> its in the 'fs' module proposal
[11:00] <ashb> of which fs-base is meant ot be a subset
[11:17] <tlrobinson> ok wtf is going on here:
[11:17] <tlrobinson> "5.4.3.2.1".split(".").map(parseInt)
[11:17] <tlrobinson> returns
[11:17] <tlrobinson> 5,NaN,NaN,2,1
[11:18] <tlrobinson> "5.4.3.2.1".split(".").map(function(n){ return parseInt(n); })
[11:18] <tlrobinson> is correct: 5,4,3,2,1
[11:20] <evilstreak> it passes multiple arguments
[11:20] <evilstreak> parseInt uses the second argument as a radix
[11:20] <tlrobinson> ah
[11:20] <evilstreak> "5.4.3.2.1".split(".").map(function(a,b,c,d){print(a.toSource(),b.toSource(),c.toSource())})
[11:20] <tlrobinson> makes sense
[11:24] <ashb> tlrobinson: does your fs.glob("~user/foo") expand that or not?
[11:27] <ashb> also isn't it like 3:30am there now?
[11:27] <evilstreak> geekery never sleeps
[11:27] <ashb> this is true
[11:27] <tlrobinson> ashb: i don't think we do home dir expansion
[11:28] <tlrobinson> and yes
[11:47] <tlrobinson> have we discussed how packages that need to built should work?
[11:48] <tlrobinson> just include a value in package.json that gets executed or something?
[11:48] <tlrobinson> "build" : "make"
[11:48] <tlrobinson> "build" : "rake"
[11:48] <ashb> i certainly mentioned it
[11:48] <tlrobinson> etc
[11:49] <ashb> "scripts": {
[11:49] <ashb> "install": "install.js",
[11:50] <ashb> hmmm - i thought we had external dependencies in there too?
[11:50] <ashb> i can't see it anymore
[11:51] <evilstreak> I think I saw it when I was writing the one for markdown
[11:51] <evilstreak> yeah
[11:51] <ashb> its not there now
[11:51] <evilstreak> http://wiki.commonjs.org/wiki/Packages/B
[11:51] <evilstreak> dependencies
[11:52] <ashb> external - i.e. on things lib openssl or cmake
[11:52] <evilstreak> the example is about gnutls and openssl
[11:52] <evilstreak> and webkit
[11:53] <ashb> hmmm, except dependencies field is for other JS packages
[11:53] <evilstreak> then you probably need to update that page to clarify
[11:56] <ashb> hmmm yes, that is a bad example really
[13:41] <olivvv> Just curious, but since jaxer has been open-sourced (GNU), is anybody planning to integrates parts of into his own js server ?
[13:42] <ashb> i didn't realise it has been
[13:42] <evilstreak> we have an awesome production-ready server already
[13:42] <evilstreak> <_<
[13:46] <olivvv> yes but no dom
[13:46] <olivvv> I m the js dom troll
[13:47] <olivvv> that's why jaxer was so cool
[13:47] <olivvv> http://github.com/aptana/Jaxer/tree/master/server/
[13:48] <ashb> ]hmmm gpl - lame
[13:48] <evilstreak> we do have a DOM
[13:48] <evilstreak> just, you know, only level 1
[13:48] <ashb> level 2
[13:48] <ashb> just not HTML
[13:48] <evilstreak> score
[13:49] <ashb> (the HTML dom API is separate to the Core XML one)
[13:49] <evilstreak> GPL is lame
[13:52] <olivvv> evilstreak: just DOM level 1 sounds similar to : computer 85% compatible PC
[13:52] <MisterN> sounds like a mac
[13:53] <evilstreak> olivvv: level 2, not level 1. I was just guessing since ashb is the one who wrote it
[13:53] <olivvv> well okay but ashb told me yesterday it was xml only not html
[13:54] <evilstreak> no, it's HTML
[13:54] <evilstreak> that was a requirement for us
[13:54] <ashb> it parses HTML
[13:54] <ashb> it just doesn't have this:
[13:54] <evilstreak> we want to be able to parse HTML from over t'web
[13:54] <ashb> http://www.w3.org/TR/DOM-Level-2-HTML/
[13:54] <ashb> everything in http://www.w3.org/TR/DOM-Level-2-Core/ we have
[13:55] <olivvv> so popular js libraries do work ?
[13:55] <ashb> like i said. sizzle does, and jquery probably does but i've not tested
[13:55] <olivvv> its flusspferd ?
[13:55] <MisterN> it should be possible to get them to work
[13:55] <ashb> yeah - its a branch in flusspferd at the moment
[13:56] <evilstreak> yes, we're part of the hippo gang
[13:56] <ashb> going to merge it in for the next release
[13:56] <olivvv> great
[13:56] <olivvv> does it run on windows ?
[13:56] <ashb> yes
[13:57] <olivvv> I'm gonna to play with it when its ready
[13:57] <ashb> k
[13:57] <olivvv> Will there be a cloud hosting available soon ?
[13:57] <evilstreak> we should be putting a new juice release out in, erm, a couple of weeks at the latest?
[13:57] <olivvv> I need to move out of aptana cloud
[13:58] <evilstreak> which will have installers for windows and os x
[13:58] <ashb> dont have any short term plans for cloud hosting no.
[13:58] <evilstreak> (possibly, binaries at the very least)
[13:59] <ashb> a single zip-bar binary is actually easier to deal with than an installer
[13:59] <MisterN> olivvv: nothing stopping you from getting generic cloud hosting and putting flusspferd+juice in there.
[13:59] <ashb> olivvv: how much are you paying for aptanna?
[14:00] <olivvv> ashb: quite expensive, I think 25$
[14:01] <olivvv> I need to check
[14:01] <ashb> per /mo?
[14:02] <MisterN> ashb: is there a dedicated / key on your keyboard? because my mental keyboard cost model says that "month" is cheaper than "/mo"
[14:02] <evilstreak> errr
[14:02] <evilstreak> who doesn't have a / key?
[14:02] <ashb> german keyboards :)
[14:02] * MisterN <-
[14:02] <ashb> MisterN: yes there is
[14:02] <evilstreak> that must suck for URLs
[14:03] <ashb> its next to the right shift key
[14:03] <MisterN> evilstreak: but i have a <> key
[14:03] <MisterN> \o/
[14:03] <MisterN> and of course umlauts
[14:03] <olivvv> okay last bill was 14 euros
[14:03] <evilstreak> we have < and > keys
[14:04] <MisterN> olivvv: that's expensive?
[14:04] <olivvv> no
[14:04] <evilstreak> HTML would be a pain otherwise
[14:04] <oberhamsi> lol, try us international for best of both worlds ;)
[14:04] <MisterN> evilstreak: anyways, i have no / key.
[14:04] <MisterN> olivvv: why do you need to get out then? :)
[14:05] <olivvv> Service is dying
[14:05] <olivvv> Jaxer is not in aptana 2.0
[14:05] <olivvv> upload is currently broken
[14:05] <olivvv> I actually hate eclipse stuff
[14:05] <MisterN> oic
[14:06] <olivvv> and jaxer service is too be discontinued end of 2010
[14:07] <MisterN> olivvv: is aptana dying? or why?
[14:08] <olivvv> jaxer is dead
[14:08] <olivvv> and aptana is probably not in best shape
[14:08] <MisterN> olivvv: are they moving to rails? that's what the website seems to indicate
[14:09] <olivvv> looks like that
[14:09] <olivvv> they dropped jaxer and php
[14:10] <olivvv> and seem to focus on ruby things
[14:10] <ashb> oh an IDE built around eclispe, that'll go down well
[14:11] <ashb> like a lead ballon
[14:11] <MisterN> eclipse is just perfect for making buggy ides
[14:12] <olivvv> My last attempts to upload my file to the aptana cloud, resulted in emptying all my files ...
[17:23] <marshall_law> hey guys
[17:27] <jmerlin> sup
[17:29] <marshall_law> so it looks like i'm late to the party -- CommonJS looks really nice
[17:30] <marshall_law> i'm actually excited it's picking up steam and more adoption, i'm hoping it's something we can put into Titanium soon
[17:30] <marshall_law> tlrobinson: you've been busy I see :)
[17:42] <Wes-> what's titanium?
[17:42] <cpojer> titanium is an application development platform similar to adobe air
[17:42] <Wes-> and air is for writing flash stuff?
[17:42] <marshall_law> it's basically a desktop and mobile platform for javascript
[17:42] <cpojer> Wes-: with air you can write apps with js/html/css
[17:43] <marshall_law> some people call the desktop edition the open source version of AIR :)
[17:43] <cpojer> the cool thing is that with tiatnium
[17:43] <cpojer> *titanium
[17:43] <cpojer> you can write apps for both android and the iphone at the same time
[17:43] <cpojer> and you only need minor modifications to run them
[17:43] <Wes-> nice -- does indeed sound useful!!
[17:43] <marshall_law> i think we're a perfect candidate for consuming the API work y'all have done so far
[17:43] <cpojer> the problem is just that those apps are generally slower (obviously)
[17:44] <cpojer> therefore it is bad to actually use a framework like mootools
[17:44] <marshall_law> at least, in desktop initially :)
[17:44] <Wes-> good, fast, on time
[17:44] <Wes-> pick two
[17:44] <cpojer> marshall_law: are you a titanium dev?
[17:44] <marshall_law> cpojer: yeah, lead dev for desktop
[17:45] <cpojer> marshall_law: cool stuff, you should totally embrace mootools some more
[17:45] <cpojer> did you hear that? Who just said that. I do not know
[17:45] <marshall_law> cpojer: thanks :) not sure how we can embrace it more, we have it in our dev tool, and we support just about any/every AJAX lib at this point.. though we do have some hack/workarounds for jquery's custom XHR code
[17:46] <marshall_law> oh, we had to do something similar for mootools recently
[17:46] <cpojer> marshall_law: yes I know ;) Its very cool that you have included it by default
[17:46] <marshall_law> hehe :)
[17:46] <cpojer> is it anything that we should fix on our side?
[17:46] <marshall_law> cpojer: not sure if it's something you'd need to
[17:47] <cpojer> ah ok
[17:47] <marshall_law> basically, we implemented a custom URL scheme
[17:47] <cpojer> so basically you broke something
[17:47] <cpojer> :P
[17:47] <cpojer> right
[17:47] <marshall_law> and some JS libs only allows 0 http status from file URLs
[17:47] <marshall_law> so we had to put our schemes in the logic
[17:48] <marshall_law> (our custom scheme is local/file based)
[17:48] <cpojer> right
[17:48] <Wes-> how is that deployed?
[17:48] <cpojer> would you mind linking me to the changes that you made?
[17:49] <marshall_law> sure np
[17:50] <marshall_law> Wes-: we have a branch of webkit
[17:51] <Wes-> ah, thought you were using file:// as a way to substitute for a CDN or something
[17:51] <marshall_law> :) we plug the underlying network API
[17:51] <marshall_law> in windows and linux that's curl, in osx it's NSProtocol
[17:51] <ashb> why not curl on osx too?
[17:52] <Wes-> I actually *did* use file:// as a substitute for a CDN, once upon a time
[17:52] <Wes-> ~1999
[17:52] <cpojer> webkit is the platform of the future to render applications (until someone develops a better platform, but that is not in sight) :)
[17:52] <Wes-> "if you want a faster experience, download this package"
[17:52] <marshall_law> ashb: webkit doesn't use curl in OSX
[17:52] <cpojer> marshall_law: we have a very clean implementation lying around somewhere to support file:// with request
[17:52] <Wes-> Of course, back then, even bouncing for 304s was slow (think: 28.8kbps)
[17:52] <marshall_law> ashb: we have to plug whatever webkit uses so the URL loads correctly :)
[17:52] <ashb> ah
[17:53] <marshall_law> cpojer: nice..
[17:53] <cpojer> (in case you need it?)
[17:54] <marshall_law> cpojer: http://github.com/appcelerator/titanium_desktop/blob/master/modules/ti.UI/Resources/all/ui.js#L43
[17:55] <cpojer> ohhh
[17:55] <cpojer> please do not do that
[17:55] <marshall_law> lol
[17:55] <cpojer> do
[17:55] <cpojer> are you shipping moo 1.2.4?
[17:55] <marshall_law> i believe we got the patch from a community member, FWIW
[17:55] <marshall_law> mm... i need to check
[17:55] <cpojer> not from our community ! :P
[17:55] <marshall_law> one sec
[17:55] <marshall_law> actually, do you know keeto?
[17:56] <marshall_law> lol
[17:56] <cpojer> Request.implement('isSuccess', function(){ ... }); instead of going through the prototype
[17:56] <cpojer> oh
[17:56] <cpojer> keeto is in fact very cool
[17:56] * marshall_law blames keeto for all his problems
[17:56] <marshall_law> ah ok
[17:57] <cpojer> its a simple fix, but that should wrap the function with mootools specific code that is *maybe* needed
[17:57] <cpojer> I'm not sure if its needed for isSuccess at some point in request.html or request.json, but safe is safe
[17:57] <marshall_law> cool, one sec
[17:58] <marshall_law> we're shipping 1.2.1 actually
[17:58] <marshall_law> O:-)
[17:58] <cpojer> that is horribly broken!
[17:58] <cpojer> well for 1.2.1 the prototype thing is probably better
[17:59] <marshall_law> lol
[17:59] <cpojer> but if its possible for you, you should update to 1.2.4 - it does not have any breaking changes
[17:59] <marshall_law> hmm
[18:01] <marshall_law> I probably need to run through all these libs and make sure they're the latest
[18:01] <cpojer> 1.2.1 is more than a year old
[18:01] <cpojer> :D
[18:03] <marshall_law> I think that was the last time we updated
[18:03] <marshall_law> :)
[18:03] <cpojer> :)
[18:12] <keeto> huh?
[18:12] <keeto> what did I do?
[18:12] <keeto> oh.. hi marshall_law. :D
[18:12] <marshall_law> hey keeto :)
[18:14] <keeto> cpojer: gimme a break! :P
[18:14] <cpojer> keeto: all good!
[18:15] <keeto> that was what? october?
[18:15] <cpojer> its 1.2.1! it would be different if it was 1.2.4
[18:15] <keeto> marshall_law?
[18:15] <marshall_law> keeto: yeah... maybe earlier even
[18:15] <marshall_law> keeto: it came over with our migration from marshall/titanium
[18:15] <marshall_law> which was in June
[18:16] <marshall_law> 7 months ago feels like an eternity
[18:17] <keeto> actually, I was talking about october 2008. :P
[18:17] <keeto> but I guess it was more decemberish.
[18:17] <keeto> of feb? PR2 period.
[18:17] <keeto> *or
[18:17] <marshall_law> keeto: http://github.com/marshall/titanium/commit/0c947763c41472a059b9d589dfe5df0af2ba0a6b
[18:17] <marshall_law> may!
[18:17] <keeto> oh? it was just this may? o.O
[18:18] <keeto> I could have sworn it was earlier. x)
[18:18] <keeto> ah time! how weird thy workings be!
[18:18] <keeto> x)
[18:18] <cpojer> :D
[18:18] <cpojer> keeto: I forgive you, you are one of the few people who actually understand the magic of Class
[18:19] <keeto> and we didn't have wrap back in 1.2.1 :)
[18:20] <cpojer> yes
[18:20] <cpojer> is what I said above :)
[18:31] <jmerlin> hm, i may implement some of the commonjs specs in my project
[18:55] <cpojer> jmerlin: whats your project? :)
[18:59] <jmerlin> it's just essentially the v8 shell with tcp networking and a binary buffer module exposed atm
[19:04] <jmerlin> my binary buffer is essentially AIR's ByteArray
[19:04] <jmerlin> a few mismatches in functions, and i don't have access to the pointer via a property access (that's a good idea though)
[19:05] <jmerlin> but mine has a few more capabilities than that, mainly due to my implementation requirements
[19:17] <jmerlin> my base socket classes explicitly require binary buffers for sending/receiving data
[19:19] <jmerlin> so the binary buffer has a second pointer that indicates the maximum position that the cursor has taken since the last reset, and the buffers size is independent of what data it may actually contain, i'm working on a better system that allows me to use chunks and memory pools in C++ for async I/O and efficiency purposes but atm that's how it is
[19:20] <jmerlin> that so-called 'max' pointer allows me to easily discern what i need to send in my socket classes, on sending i simply send from index 0 to max, so the ascribed method of writing to a socket is to use any given buffer, call reset() to set max and cursor back to 0, then write the data in and call send on the socket passing the buffer
[19:21] <jmerlin> reading data takes in a buffer and writes into the raw buffer from cursor, incrementing max if the readsize + cursor is greater than it, it will only attempt to read in an amount that is equal to the size of bytes remaining in the buffer (length - max)
[19:23] <jmerlin> i want to make these buffers completely ignorant of "total" size though, by backing them transparently with 256 byte chunks of memory chained together so that the buffers shrink and grow as needed, so the 'size' will be useless and resetting will null its base chain, any writes would automatically allocate any blocks from a pool needed to fulfill the write request
[19:27] <jmerlin> the exposed api from C++ is very minimalistic allowing for writing/reading of 8bit blocks, 16bits, 32, and floats/doubles in either big or little endian, plus pointer manpulation, the rest is implemented in JS, 64bit blocks are read in two 32bits and shoved into an object with 'lowpart' and 'highpart' set appropriately, and anciliary functions for reading/writing strings, null-terminated strings, arrays of values, and even "template objects" for (de)serial
[19:27] <jmerlin> i like it better personally than the proposals on the wiki and anything else i've seen
[19:30] <jmerlin> anciliary = ancillary*
[19:48] <jmerlin> but primarily i was thinking about implementing my own module type system because this project will be loading LOOOOOTS of plugins and i don't want to pollute a global space, so i'll probably end up implementing the 1.0 of that, maybe a few others
[19:51] <marshall_law> our "raw byte" structure is pretty minimalist at the moment, it's ducked type like a String more or less
[19:51] <marshall_law> duck typed *
[19:52] <marshall_law> it's not very fast either, it's just a vector of chars ;)

 

 

Logs by date :