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

2010-04-14:

[16:14] <jbrantly> I think my browser loader is stable enough now for a general release. I'm planning on announcing it on the mailing list. Is there some procedure for adding it to the wiki? The project is located at http://github.com/jbrantly/yabble
[16:22] <kuya> it looks nice to me
[16:23] <jbrantly> thanks
[16:58] <dmachi> jbrantly: looks cool, i took a look a couple days ago when you pinged, but i'll give it a play this weekend. I put my Titanium loader up too last week and almost have enough of the core libs ported to have pintura running there :)
[17:33] <deanlandolt> dmachi: what are you missing to get pintura going?
[17:34] <dmachi> deanlandolt: just time to get the Jsgi wrapper to work with the webserver titanium exposes.
[17:34] <deanlandolt> oh, cool -- i could help with that
[17:35] <deanlandolt> can you point me to some docs on the webserver?
[17:35] <dmachi> deanlandolt: yeah, sec...but thats the bulk of the problem , tiny docs :)
[17:36] <deanlandolt> well then, point me to the code...that should be fine
[17:36] <deanlandolt> jsgi wrappers are easy -- understanding the subtlies of various webservers is the hard part...docs probably wouldn't be enough anyway :)
[17:37] <dmachi> https://developer.appcelerator.com/apidoc/desktop/1.0/Titanium.Network.createHTTPServer.html and https://developer.appcelerator.com/apidoc/desktop/1.0/Titanium.Network.HTTPServerRequest.html
[17:38] <dmachi> deanlandolt: yeah, they just don't seem to expose much of the underlying webserver. Let me see what i've already committed in that regard.
[17:38] <dmachi> deanlandolt: sec
[17:43] <dmachi> deanlandolt: i dont' have anything for that worth putting up there yet, i had just forked jsgi-node from kris and started working on a copy of it yesterday. http://github.com/dmachi/jsgi-titanium
[17:43] <dmachi> deanlandolt: though there is little to see in that repo aside from the original code :P
[17:43] <deanlandolt> cool...though the simple-worker (based on java's simple server) may be closer to the api: {"_id":"moduleName2","_rev":"5-00b222b6f67252f2ddbcf54164015b83","type":"module","couchapp":
[17:43] <deanlandolt> {"manifest":["type","couchapp.json"],"description":"CouchApp for
[17:43] <deanlandolt> Module2","objects":{},"signatures":
[17:43] <deanlandolt> err...damn...
[17:43] <deanlandolt> {"moduleName2.js":"67c32896f91c169ae5ecd15ffab9fc5c"},"name":"Moudle
[17:43] <deanlandolt> 2"},"_attachments":{"moduleName2.js":
[17:43] <deanlandolt> {"stub":true,"content_type":"application/x-javascript","length":
[17:43] <deanlandolt> 1012,"revpos":5}}
[17:43] <deanlandolt> copypaste FAIL!
[17:44] * ashb hands deanlandolt a pastebot ;)
[17:44] <deanlandolt> ashb: was just trying to paste a url :)
[17:45] <ashb> i gathered. but i'm never one to pass up an opporuinity to insult someone :D
[17:45] <deanlandolt> you wouldn't be a very good geek if you could :)
[17:46] <deanlandolt> dmachi: http://github.com/kriszyp/jack/blob/master/lib/jack/handler/simple-worker.js
[17:46] <deanlandolt> that should be a LOT clsoer to what you'll need for titanium
[17:47] <ashb> hmmm what did i do with the jsgi library for Smart....
[17:48] <dmachi> deanlandolt: ok, i have one that i was pretty close to having working from inside that directory...I'll take a look here in a bit, thanks.
[17:48] <deanlandolt> dmachi: yeah, i'm looknig through your code now to see if anything jumps out at me
[17:51] <deanlandolt> dmachi: have you not pushed anything? looks like it's still just jsgi-node
[17:57] <dmachi> deanlandolt: yeah, i havne't pushed that one yet. Here is the one that was based of one of the jack/handler imps http://github.com/dmachi/Titanium-CommonJS/blob/master/lib/JsgiHandler.js Its pretty close to working. The middleware processes. I'm doing something wrong during normalizing of the repsonse back to the Titanium response object.
[17:59] <deanlandolt> dmachi: you can dump this switch: http://github.com/dmachi/Titanium-CommonJS/blob/master/lib/JsgiHandler.js#L81-84
[18:00] <dmachi> yeah, comes from tracing and trying to figure out where it was breaking.
[18:01] <deanlandolt> dmachi: the titanium api says response.write can take string or byte content...how does it take byte content?
[18:02] <Wes> one bit at a time?
[18:02] <deanlandolt> does it have a binary api? if so, that's all you need
[18:02] <Wes> num num num
[18:02] <deanlandolt> heh
[18:03] <deanlandolt> so yeah, does it take an array of signed ints?
[18:03] * Wes is having fun today
[18:03] <deanlandolt> err, unsigned...sorry
[18:03] <Wes> I wonder if I should be implementing JSGI -- I'm working on web services which can take on customized code depending on the URL
[18:03] <deanlandolt> forEach(chunk) { response.write(chunk.toByteString()) } is all that's needed for the reply
[18:04] <deanlandolt> Wes: what do you mean by customized code?
[18:04] <Wes> /method/X runs X.js, /method/X/Y runs X.js, but loads Y.js in at runtime
[18:04] <ashb> Wes: JSGI is arguably not that different from straight CGI
[18:04] <ashb> just slightly more refined
[18:04] * Wes nods
[18:04] <ashb> and obviously more suited to be persistent
[18:04] <Wes> I am using old-school CGI for my webserver interface, but that's just 'cause it's handy to do so
[18:04] <deanlandolt> yeah...i'd say it's more HTTP'ish than cgi
[18:04] <ashb> since iirc CGI can't be persistent?
[18:04] <Wes> well, depends on what you mean by persistent :)
[18:05] <Wes> you can be as persistent, as say, php
[18:05] <dmachi> deanlandolt: i had tried to write it like that, but haven't had success so far. When i last worked on it a couple days ago I was thinking I was just to rebuild titanium and actually expose the async webserver
[18:05] <ashb> one process handling more than one request
[18:05] <deanlandolt> dmachi: have you implemented String.prototype.toByteString yet? if so that's needed by the jsgi spec
[18:05] <Wes> ashb: Ah, no, can't do that with CGI
[18:05] <deanlandolt> not needed, but some kind of toByteString is
[18:05] <Wes> I'm using the 1997 perl model right now
[18:06] <Wes> except, you know, with Javascript
[18:06] <deanlandolt> oh, there's an async web server? well, then node-jsgi would make more sense
[18:06] <deanlandolt> dmachi: but the bytestring stuff will probably be the biggest PITA
[18:06] <dmachi> deanlandolt: deanlandolt at the moment i'm doing test driven development using pintura as the test case to get the basics working, then will have learned enough to reorg a little bit and flesh out the implementations where necessary.
[18:07] <dmachi> deanlandolt: let me see if they have anything for it already
[18:07] <deanlandolt> cool...just ping me if you have any questions...i'm pretty intimate w/ both jsgi and pintura
[18:08] <deanlandolt> pintura's like an adopted child...i didn't created it but i love it like my own
[18:08] <Wes> deanlandolt: will you want to strangle it when it turns 18?
[18:08] <dmachi> deanlandolt: cool, thanks. I work with kris too, so it should be going pretty soon
[18:08] <Wes> dmachi: which kris? zyp?
[18:08] <deanlandolt> i sometimes want to shake it now
[18:09] <dmachi> Wes: yah
[18:09] <Wes> deanlandolt: don't do that, you can damage it's brain
[18:09] <deanlandolt> heh :)
[18:09] <dmachi> deanlandolt: i think the blob stuff titanium has will get me what i need https://developer.appcelerator.com/apidoc/desktop/1.0/Titanium.API.createBlob
[18:09] <dmachi> deanlandolt: at least to get started.
[18:10] <deanlandolt> perfect
[18:16] <dmachi> deanlandolt: oh, didn't see your question before. The underlying server is http://pocoproject.org/docs/Poco.Net.HTTPServer.html
[18:18] <dmachi> deanlandolt: so i think for now i need to use one of the sync versions based on jack/handler, but if I can expose some of the other methods on the HTTPResponseObject, i should be able to get it to be async and swithc to the node version.
[18:19] <deanlandolt> perhaps, though i didn't see anything about async in the link you just sent...looks like it's a multithreaded server
[18:19] <deanlandolt> but event-based servers are probably overkill for titanium...after all, it's a single user situation
[18:20] <deanlandolt> async's kinda silly in that context AFAICT
[18:21] <dmachi> sorry i didn't mean it from that perspective, but from the api's perspective.
[18:21] <deanlandolt> so you can do just what simple-worker does and use promise.when
[18:22] <dmachi> yeah, i dont' expect too much more trouble, just limited time and lots of new stuff to learn :)
[18:23] <deanlandolt> you can paper over all of that though by just doing a forEach(function(chunk) { response.write(chunk.toByteString()) }); and closing the response using promise.when
[18:24] <dmachi> k
[18:34] <dmachi> deanlandolt: actually, thats what i had tried to do, but there is no response.close(), which is why i had gone digging in the Poco api docs to see if it really existed.
[18:44] <kuya> 3/5
[18:44] <kuya> oops
[18:47] <Wes> kuya: 9/10, that was awesome
[18:55] <kuya> >.<
[18:56] <kuya> too many window swapping shortcuts
[18:59] <Wes> kuya: my usual accident is to repeat myself (cursor up enter)
[19:00] <dmachi> Wes: its jjjjjjjjj from vi for me :P
[19:00] <kuya> hehe - i often try and save irc with :wa too ;)
[19:01] <dmachi> :)
[19:01] <Wes> dmachi: you know what I /hate/ - is accidentally switching to vi, thinking it's emacs, hitting ^X ^S and wondering WTF my terminal just froze :D
[19:01] <dmachi> hehe
[19:01] <kuya> why isnt there a js powered console text editor!? thats what i want to know...
[19:02] <dmachi> i believe there is a vi impl written in js, wouldnt' be too hard to get working in one of these fancy envs :)
[19:03] <kuya> your probably right :)
[19:04] <kuya> i dare say vim could be compiled with js support...
[19:06] <Wes> kuya: GPSEE has enough tools that you could build one from scratch, you could use the jsie.js REPL understand how to use curses and manipulate windowed areas of the screen
[19:07] <kuya> i am aware of this :]
[19:07] <kuya> the thing is
[19:07] <kuya> i want to run the thing inside the browser
[19:08] <Wes> Oh, well that complicates things a little
[19:08] <kuya> write a curses implementation for canvas
[19:08] <dmachi> there is definitely a vi thing that you can use with textareas
[19:08] <Wes> Get real creative - write a canvas implementation of GPSEE's curses module (which is quite high-level)
[19:08] <Wes> then you could have a cross-platform editor!
[19:09] <Wes> any modern browser, any modern UNIX
[19:09] <kuya> well i want to write a new term that has a little more features than your regular one
[19:10] <kuya> i wish bespin was better...
[19:10] <dmachi> one of several..http://www.ibr.cs.tu-bs.de/users/gutbrod/viedit/ (vi textarea upgraders)
[19:11] <kuya> have you used vimperator?
[19:11] <kuya> (it has a quite excellent inspector for pages and chrome if you ever cant be bothered with chromebug )
[19:15] <dmachi> nope, hadn't heard of it
[21:40] <rolfb> anyone have good documentation on writing modules?
[21:43] <kriskowal> rolfb a how-to?
[21:44] <rolfb> how-to or what special objects are available
[21:44] <kriskowal> how to write original work, how to port various styles, how to craft modules that work as scripts, how to use them in browsers?
[21:44] <rolfb> "write original work"?
[21:44] <kriskowal> the spec is pretty clear about what objects you can depend on being available http://wiki.commonjs.org/wiki/Modules/1.1.1
[21:44] <kriskowal> although it's certainly not written to be instructive or narrative
[21:45] <rolfb> aha
[21:46] <rolfb> seems i didn't see Modules for all the bullets in the list
[21:47] <kriskowal> hm, i'm not sure what you mean. "Modules" is not a variable, if that's what you mean.
[21:47] <rolfb> no
[21:48] <kriskowal> or, is it just hard to see the big picture?
[21:48] <rolfb> sorry
[21:48] <kriskowal> from all the details?
[21:48] <rolfb> i didn't see Modules for all the bullet points in the wiki, and skipped to Packages
[21:48] <kriskowal> oh, i see
[21:48] <rolfb> my mistake :)
[21:48] <rolfb> thanks for pointing me in the correct direction
[21:49] <kriskowal> of course, np
[21:50] <rolfb> also, i generally have an issue with following to many links unless it is structured like a repository
[21:50] <rolfb> :P
[21:53] <rolfb> kriskowal: could you point in the direction of smaller package for commonjs? want to look at the structure and source
[21:53] <rolfb> of a*
[21:54] <ashb> http://github.com/ashb/jsgi-vhost
[21:54] <ashb> is about as small as you can get
[21:54] <kriskowal> rolfb, of an implementation?
[21:54] <ashb> (the packages.json isn't quite complete it seems
[21:55] <rolfb> ashb: indeed
[21:55] <rolfb> kriskowal: like ashb's example
[21:55] <ashb> you can get fair simpler
[21:55] <ashb> i just happened to havethat open
[21:55] <ashb> infact doesn't the modules page have some at the end?
[21:55] <rolfb> ashb: too simple is too simple
[21:55] <rolfb> :P
[21:56] <ashb> fair enough :)
[21:56] <rolfb> but yes, i wasn't clear on that but a repo would be great
[21:56] <kriskowal> yeah, there are about 50 narwhal packages, but they're not up to spec yet
[21:56] <kriskowal> bbiab
[21:57] <rolfb> hmm
[21:57] <rolfb> would like to see some node.js ones
[21:57] <rolfb> :)
[21:59] <ashb> it depends what the module does. but the basic structure is no different
[21:59] <ashb> just the modules it in turn requires
[22:00] <rolfb> figured as much

 

 

Logs by date :