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

2011-01-07:

[9:08] <gozala> kriskowal: ping!
[9:08] <kriskowal> hey
[9:08] <kriskowal> just integrated some of your patches to q
[9:09] <kriskowal> and put the remaining ones in q/kriskowal/experimental
[9:09] <kriskowal> particularly, i'm not ready to commit to swallowing all exceptions yet
[9:09] <kriskowal> almost ready to pull the trigger on duck-type promises though (gozala^)
[9:10] <gozala> Great
[9:10] <gozala> > particularly, i'm not ready to commit to swallowing all exceptions yet
[9:10] <gozala> what do you mean
[9:11] <kriskowal> catching all exceptions thrown in promise message handlers and returning rejections instead.
[9:11] <gozala> you mean you don't want to integrate bugfix?
[9:11] <kriskowal> i merged those patches into an experimental branch
[9:11] <kriskowal> so i can sleep on it.
[9:12] <gozala> can you give me a link of a change you're talking about ?
[9:12] <kriskowal> i have an inkling that it might be useful to distinguish programmer errors from rejections, but i'm not sure
[9:12] <kriskowal> yeah, sec
[9:13] <gozala> I don't remember myself proposing that change :/
[9:13] <kriskowal> https://github.com/kriskowal/q/compare/master...experiment-exceptions
[9:13] <kriskowal> your patch 002eb3f4
[9:14] <kriskowal> there also appears to be a bug in your assert.equal, but it only shows up if the test fails
[9:15] <gozala> Oh I think you missunderstood that one
[9:15] <gozala> https://github.com/kriskowal/q/issues#issue/10
[9:15] <gozala> first bullet
[9:15] <kriskowal> here're the changes that i *did* integrate https://github.com/kriskowal/q/compare/v0.2.3...master
[9:17] <kriskowal> gozala, yeah i've run into that issue. it's a compelling reason to do some checks.
[9:17] <kriskowal> or to do as you suggest and trap the exception in a rejections.
[9:18] <gozala> Actually I did not thought of exceptions
[9:18] <gozala> that maybe fired by listeners
[9:19] <gozala> Only thing is that
[9:20] <gozala> Q.get(promise, 'foo') should be rejected IMO
[9:20] <gozala> if promise is resolved to null / undefined
[9:21] <kriskowal> yeh, there are two issues intertwined.
[9:21] <kriskowal> i'll keep it on my mind.
[9:22] <gozala> kriskowal: Actually I was going to talk to you regarding q-comm
[9:22] <kriskowal> in the interim, it's time for me to sleep. anything else you have in mind since we're awake at the same time?
[9:22] <kriskowal> kk
[9:22] <gozala> if you have few secs I'll ask now
[9:23] <kriskowal> go ahead
[9:23] <gozala> or I can do it other time
[9:23] <gozala> so first of all it's awesome and I was exactly doing similar thing
[9:23] <gozala> inspired by http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[9:23] <gozala> :)
[9:24] <gozala> so in jetpack we're integrating multiprocessing
[9:24] <gozala> so that chrome modules (interacting with dom / io)
[9:24] <gozala> will run into one process and rest in other
[9:24] <kriskowal> gotcha
[9:25] <gozala> you're work seems to be a good fit there
[9:25] <kriskowal> so, yeah, we're working based on the same stuff there
[9:25] <gozala> only thing that is not clear for me yet is
[9:25] <kriskowal> there are a few things that markm wants me to change still
[9:25] <kriskowal> like having far references observable by when
[9:25] <kriskowal> which means that you'd resolve to a value that's still technically a promise, which is odd, but useful
[9:26] <gozala> oh I see
[9:26] <kriskowal> still scratching my head about how to do that.
[9:26] <gozala> I still have to catch up with where you are though
[9:26] <kriskowal> sure
[9:27] <gozala> so my question was
[9:27] <kriskowal> i might talk about it at jsconf
[9:27] <kriskowal> also, i dropped a resume in the jetpack team's bin, fyi
[9:27] <gozala> If I got it right you have a one peer
[9:27] <gozala> that is not resolved
[9:27] <gozala> on both sides
[9:27] <kriskowal> yeah
[9:28] <kriskowal> a single object to a single object connection is where it all starts.
[9:28] <gozala> What I want to do is
[9:28] <gozala> to have more then one
[9:28] <kriskowal> yeh
[9:28] <gozala> like a resolved object
[9:28] <gozala> whose properties may be promises
[9:28] <gozala> that never resolve
[9:29] <gozala> do you have opinion about that ?
[9:29] <kriskowal> there are a variety of approaches. my housemate wants to have a broader scope for these far references than limiting them to a connection, so i've gotta come up with some sort of adapter that can gracefully reconnect a promise with a remote reference
[9:29] <kriskowal> yeah, that's entirely possible
[9:29] <kriskowal> you can make your root object a map to a variety of objects with Q.def
[9:30] <gozala> nice
[9:30] <kriskowal> the only thing you have to do is mark all your remotes with Q.def
[9:30] <kriskowal> your root object doesn't even have to be a Q.def in that case.
[9:30] <gozala> actually I'd like to do it automagically
[9:30] <gozala> using decode / encode
[9:31] <kriskowal> that's sortof what happens anyway
[9:31] <gozala> if what you encode is different from JSONified version than you swap it with Q.def
[9:31] <kriskowal> if your root object is {a: Q.def({?})}, it'll get serialized like {"a": {"@": "ID"}}
[9:31] <gozala> yeah I sew that
[9:32] <gozala> So you said you might want to get into jetpack team ?
[9:33] <kriskowal> it might be a good fit
[9:33] <kriskowal> i'm in the market for a job again
[9:33] <gozala> That's would be awesome, I'll talk with folks
[9:33] <gozala> it would be awesome to have you onboard !!
[9:33] <gozala> I also think that your interests are very good feet
[9:34] <gozala> a problems we're trying to solve in jetpack
[9:34] <gozala> Thanks for tips
[9:35] <gozala> and have good night!!
[9:35] <kriskowal> if you're finding yourself coincidentally need q-comm, i believe you
[9:35] <kriskowal> good night
[9:35] <gozala> It's morning here, but tnx :)
[9:36] <kriskowal> ah, yeah. morning zzzz :P
[9:47] <sid3k> hi all. is there anyone tried to run javascript library of nodejs on a browser?
[13:30] <Wes-> Jeez
[13:30] <Wes-> I can't believe, it's almost three years in and we are still arguing about whether or not eager evaluation of module factories is a good idea or not
[16:02] <Najjah> hello everyone. Does n1 here know javascript for desktop? Is there a site or something where I can get information about it?
[16:03] <dmachi> what do you mean by that exactly Najjah
[16:45] <Najjah> any thoughts?
[16:52] <dmachi> Najjah: what do you mean by javascript for desktop exaclty
[16:52] <dmachi> are you just wanting an interpreter that runs on a desktop, are you trying to make desktop applications with js, etc?
[17:25] <Najjah> I'm actually trying to create small apps to be run from a .JS file directly from desktop
[17:25] <Najjah> a non-web app
[17:26] <Najjah> I work with BI using Hyperion Intelligence Explorer and this software allows me to write scripts in JS. However, it's not based on web objects. Therefore I don't have a window object for instance
[17:26] <Najjah> there are some slight differences from web JS and sometimes it's harder to find out how to do something once I can only find web stuff
[17:32] <mschwartz> http://www.adobe.com/products/air/
[17:34] <dmachi> so you can do that with nodejs and a few other js inteprreters (node being the popular one) if you want just scripts/no gui. THings like adobe air and appcellerator titanium can let you write gui apps locally using web tech (which doesn't mean you open a web browser and hit a local webserver though).
[17:35] <Najjah> interesting
[17:35] <Najjah> I'll take a look. thanks.
[17:36] <Najjah> are they some kind of api? or a new environment that must be installed in the sys?
[17:36] <mschwartz> user has to install AIR
[17:36] <mschwartz> but the download/install is easy to integrate in your WWW pages
[17:37] <Najjah> cool. thanks.
[17:37] <dmachi> with titanium it builds a native app with the js and all embedded, no secondary install (at the expense of larger downlaod of course)
[17:38] <dmachi> well native app isnt' what i meant, native app bundle probably a better way to describe i suppose.
[19:59] <mschwartz> FWIW, I just posted to the Helma google group a scheme I devised for dealing with binary data in Javascript, including the ability to store into databases, etc.
[20:07] <Wes-> mschwartz: interesting - 10 word summary?
[20:07] <mschwartz> base64encode/decode
[20:07] <mschwartz> using Java byte arrays
[20:08] <Wes-> oh, okay - similar to what we do as well
[20:08] <mschwartz> sure
[20:08] <mschwartz> it seems like a good thing to implement directly in Java
[20:08] <mschwartz> or in C/C++ for those engines
[20:08] <Wes-> Definitely - our Binary/B impl is mostly C and that's where the base64 stuff should sit
[20:08] <mschwartz> I searched on Google for a few hours looking for some scheme for helma
[20:08] <mschwartz> nothing
[20:09] <Wes-> "should" because we didn't actually get the APIs ironed out, too busy :(
[20:09] <mschwartz> http://base91.sourceforge.net/
[20:09] <Wes-> CommonJS Binary/F (I think?) has some other ideas there as well
[20:09] <mschwartz> a bit more optimal than base64
[20:10] <mschwartz> I talked in my post about how I like to store uploaded files and such in teh DB
[20:10] <mschwartz> it makes scalability of WWW sites a lot easier, and I think better
[20:10] <Wes-> neat! it makes sense to move up the char count given that CPU isn't the encode/decode choke point any more
[20:10] <mschwartz> you don't have to worry about rsync or whatever to get your files in sync
[20:11] <mschwartz> well
[20:11] <mschwartz> I talk in my post about file size issue
[20:11] <mschwartz> someone uploads a big .zip file
[20:11] <mschwartz> it takes quite a bit of CPU to encode 100MB or whatever
[20:11] <mschwartz> and about the same to decode
[20:12] <mschwartz> so you want to cache the decoded one in the filesystem
[20:12] <Wes-> are file uploads still typically base64 on the wire?
[20:12] <mschwartz> just fetch it from the db one
[20:12] <mschwartz> yes they are
[20:12] <mschwartz> download? no
[20:12] <Wes-> I wonder if there is a fast 64->91 algorithm out there? Probably no faster than 64->raw->91 (according to my gut)
[20:13] <mschwartz> ithe encoding, whatever you do, is loop bound
[20:13] <mschwartz> 100M iterations
[20:13] <mschwartz> or 25M if you do longwords
[20:13] <mschwartz> so the less operations inside the loop, the better, IMO
[20:14] <mschwartz> I'd rather have a 40% overhead and FAST than 25% overhead and slower
[20:14] <mschwartz> in any case
[20:14] <mschwartz> how often do you really need to manipulate binary on the server?
[20:14] <mschwartz> load / store to DB
[20:14] <mschwartz> maybe some image manipulation
[20:14] <mschwartz> creating zip
[20:15] <mschwartz> maybe upload an image, have the server scale it to certain dimensions
[20:18] <mschwartz> whatever server-side implementation, you clearly need glue
[20:18] <mschwartz> for helma/ringojs, you get Java
[20:18] <mschwartz> I don't think we want to write super complex mathematical code operating on vast data sets in JS

 

 

Logs by date :