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

2010-07-21:

[12:05] <pikpik> Hi, can engines such as V8CGI contain blocks of code and blocks of non-code for HTTP output (e.g. <?php ?>)?
[12:24] <pikpik> Hello?
[12:29] <pikpik> Is there any way of having embedded code blocks in an SSJS application?
[12:36] <Wes-> pikpik: Yes, but AFAIK nobody has written a parser to actually do that
[12:42] <pikpik> Wes-: Thanks!
[12:42] <Wes-> pikpik: Feel like writing one? :D
[12:44] <pikpik> Wes-: I'd love to if I were paid to, sorry. :) I'm, more or less researching, this for a fellow V8 user.
[12:44] <pikpik> *, more or less, researching
[12:58] <pikpik_> Wes-: Hi?
[12:59] <pikpik_> Wes-: Did something just happen?
[12:59] <Wes-> pikpik: Hi! Looks like the IRC node you were on went away and rejoined
[12:59] <Wes-> pikpik: If you're lokoing for a v8 ssjs solution for web content, you should look at node.js
[12:59] <Wes-> pikpik: It's sort of like Python's Twisted
[13:02] <pikpik_> Wes-: Okay.
[13:03] <pikpik_> Wes-: Ironically, I had just entered a regular expression example for ideally preprocessing embedded code blocks. :(
[13:03] <pikpik_> Wes-: That's when my connection showed everyone quitting.
[13:04] <Wes-> oh, that's hilarious
[13:04] <pikpik_> yeah
[13:21] <pikpik_> Wes-: Is there a way for me to suggest embedded code blocks for inclusion as some part of CommonJS?
[13:22] <pikpik_> Wes-: The Google Group?
[13:29] <Wes-> pikpik_: Sure - but I don't think you're going to find a lot of love there
[13:30] <Wes-> that's more a framework question than a language facility question
[13:30] <Wes-> and they are already working on JSGI
[13:31] <Wes-> But don't let lack of love dissuade you, I think these issues should at least be explored
[13:31] <pikpik_> Ok, sounds reasonable. :)
[13:59] <pikpik_> Wes-: I've posted a message on the Google Group. It isn't available yet, but I'd assume it might soon be (?).
[14:23] <pikpik_> Wes-: My topic is on the Google Group now: http://groups.google.com/group/commonjs/browse_thread/thread/b3ca1692fa830072
[15:43] <nrstott> kriszyp, is there a narwhal module that is compatible with jsgi/promise ?
[15:43] <nrstott> node-jsgi/promise rather
[15:44] <kriszyp> nrstott: you mean so that narwhal can create promises that are consumable by jsgi-node?
[15:44] <nrstott> im reworking bogart to run on node using node-jsgi but i want it to still be runnable with jackup
[15:44] <nrstott> right now im using require('jsgi/promise') for my promises
[15:44] <nrstott> i packaged your node-jsgi for npm btw
[15:44] <kriszyp> obviously you can create promises with jsgi-node's promise handler
[15:45] <kriszyp> ok, require('jsgi-node/promise') should work fine
[15:45] <nrstott> so i need to replace my require('jsgi/promise') with some shim that will use a narwhal module on narwhal and jsgi/promise on node
[15:45] <kriszyp> require('jsgi/promise') should still work on narwhal
[15:45] <kriszyp> and jack
[15:45] <nrstott> is it packaged for tusk?
[15:45] <nrstott> do i need to do that? ;0
[15:45] <kriszyp> hmmm...
[15:46] <kriszyp> no
[15:46] <nrstott> it doesn't make much sense as a narwhal package
[15:46] <nrstott> the main file is only compatible with node right?
[15:46] <kriszyp> the complication is that the jack fork that supports promises isn't in tusk either, I don't think
[15:46] <kriszyp> what jack are you using?
[15:46] <nrstott> whatever tusk installs
[15:46] <nrstott> i assumed it was 0.3 by now
[15:47] <nrstott> that assumptoin may've been incorrect
[15:47] <kriszyp> hmm, maybe it is, haven't looked recently
[15:47] <nrstott> jackup version 0.2 is what jackpu --version gives me
[15:47] <kriszyp> do promises work on it?
[15:47] <nrstott> haven't tried yet... was trying to get my hello-world.js working and immediately realized i need some kind of promise implementation
[15:47] <nrstott> does pintura run on both narhwal and node?
[15:48] <nrstott> what do you do there?
[15:48] <kriszyp> yes
[15:48] <kriszyp> I use kriszyp/jack for jack
[15:48] <kriszyp> and I am explicit about my promise module (like require("jsgi-node/promise"), although I am actually using require("promised-io/promise") as I am using promised-io as a shim for I/O diffs between narwhal and base node)
[15:49] <kriszyp> the promises generated by the promise module in promised-io and jsgi-node (and my fork of narwhal as well) are all compatible with kriszyp/jack's promise handling
[15:49] <nrstott> so promise-io works with narwhal too?
[15:49] <kriszyp> yes
[15:49] <nrstott> nice
[15:50] <nrstott> so why isn't kriszyp/jack merged into the mainline yet?
[15:50] <kriszyp> that's bascially my compatibility/x-platform handling layer, at least for now
[15:50] <nrstott> are we not agreed on JSGI 0.3 as of yet?
[15:50] <kriszyp> well, kriszyp/jack still doesn't have all the middleware modules upgraded to JSGI 0.3, I don't think
[15:50] <kriszyp> deanlandolt was going to do that at some point, but I don't think it was ever completed
[15:51] <kriszyp> and I haven't been motivated to work on it, since I only need some of the middleware modules, most of what I use is in pintura (which are all JSGI 0.3 compliant already)
[15:51] <deanlandolt> it was pretty close to completed...i've gotten way behind on everything :-/
[15:51] <nrstott> that should be what, 30 minutes of work? ;0
[15:51] <nrstott> get on it dean!
[15:52] <nrstott> j/k
[15:52] <nrstott> If there's some important blocker ill just fix it, I want to get async bogart out the door soon
[15:52] <kriszyp> cool
[15:52] <nrstott> where is kris kowal when you need him
[15:52] <nrstott> he's the one whod actually have to do the merge into 280north
[15:53] <kriszyp> I thought jack was handled more by tlrobinson
[15:53] <nrstott> isn't he on vacation?
[15:53] <nrstott> tlrobinson, are you on vacation?
[15:53] <kriszyp> and he's the one that actually works for (or owns or whatever) 280north
[15:56] <kriszyp> anyway, all my stuff (promised-io, pintura, persevere-example-wiki, etc) is pretty continuously tested on node and jack, so I know it works and you can use whatever you need from there
[15:57] <nrstott> ok
[15:57] <nrstott> i kind of hate not being able to tusk install jack and have it wokr, but im sure thatll come in the future
[15:58] <kriszyp> yeah, but I think kriskowal is going to move towards package mapping which may mean big changes (or having it go away) for tusk anyway
[15:58] <nrstott> right then i could depend on kriszyp/jack instead of mainline jack
[15:58] <hannesw> kriszyp did you ever try running your stack on ringo?
[15:58] <kriszyp> right
[15:59] <kriszyp> hannesw: I've been meaning to try sometime, I'd really like to try that out
[15:59] <nrstott> hannesw, does ringojs do JSGI 0.3
[15:59] <hannesw> nrstott yes
[15:59] <hannesw> ringo and narwhal are 95% compatible
[15:59] <kriszyp> there was something I was going to ask you about that, but can't remember atm
[15:59] <nrstott> kriszyp, what is Nodules?
[15:59] <hannesw> only major exception is file moudule
[16:00] <kriszyp> oh, what http server is built on?
[16:00] <kriszyp> jetty?
[16:00] <nrstott> hannesw, so what is the difference between ringo and narwhal, other than the file module?
[16:00] <hannesw> yes, ringo has jetty bundled
[16:00] <hannesw> major difference is ringo core/module loader is written in java
[16:00] <hannesw> and it's not multi-engine, just rhino
[16:01] <kriszyp> nrstott: nodules implements package mappings, not going to try to dump the full descr from the docs for you on IRC :)
[16:01] <kriszyp> hannesw: have you done any perf tests of http handling? just curious how it does...
[16:03] <hannesw> kriszyp i think basic hello world jsgi does around 3000 reqs/sec on my machine
[16:04] <kriszyp> have you compared to jack or node? (nice to get same box comparisons)
[16:04] <hannesw> haven't benchmarked jack recently
[16:04] <kriszyp> I know it is tough to compete with node in terms of speed, just curious if they are close at all
[16:04] <hannesw> node is making ~ 6000 reqs/sec i think last time i tried
[16:05] <kriszyp> cool, that's at least in the same ballpark, that's good to hear
[16:06] <deanlandolt> nrstott: just did a quick survey of mw modules that need conversion -- it's not that many -- i'll start checking in fixes now
[16:08] <kriszyp> and hannesw do you have any notion of "packages" in ringojs, does it do anything with them?
[16:08] <hannesw> kriszyp yes:
[16:08] <deanlandolt> kriszyp: looks like your fork has a promised-io dependency
[16:09] <hannesw> http://ringojs.org/wiki/Packages/
[16:09] <deanlandolt> tlrobinson: if you're around, would you mind having a promised-io dep added to jack?
[16:09] <hannesw> kriszyp I just installed transporter package today and it ran fine on ringo
[16:09] <hannesw> except that file->fs issue
[16:10] <deanlandolt> hannesw: how close is ringo's fs to narwhal's?
[16:10] <kriszyp> hannesw: nice, that's cool
[16:10] <hannesw> ringo's fs is filesystem/a draft 6
[16:10] <hannesw> narwhal's is draft 4
[16:10] <deanlandolt> i see
[16:11] <kriszyp> promised-io is the main compabiilty layer i am using, I bet it could easily be adapted for ringojs
[16:11] <kriszyp> so hannesw with packages, how do you refer to a module from another package, do the modules all go in the same namespace or separate ones?
[16:12] <hannesw> currently all packages are added to the module search path
[16:12] <hannesw> but I've been thinking about implementing the mapping proposal
[16:12] <kriszyp> ok
[16:12] <kriszyp> so basically like narwhal...
[16:12] <hannesw> yes
[16:46] <tlrobinson> nrstott: just got back from vacation a couple days ago
[16:47] <nrstott> tlrobinson, what's your take on the status of JSGI 0.3 and the mainline of jack?
[16:47] <nrstott> have you looked at zyps jack?
[16:47] <tlrobinson> i occasionally try to merge them but they've diverged quite a bit unfortunately
[16:47] <tlrobinson> so i back off
[16:48] <nrstott> what do we need to do to get them back on the same page? I know you have lots of stuff that depends on JSGI
[16:48] <nrstott> are you worried about the migration path?
[16:49] <tlrobinson> i don't know, i think i (or someone) just need to dedicate a weekend to it and do it
[16:50] <tlrobinson> i think someone (deanlandolt?) wrote some adapters for 0.2 <-> 03
[16:50] <deanlandolt> i wrote a 0.2 -> 0.3 -> 0.2 adapter, but not the other way
[16:51] <tlrobinson> i'd also like to make jack completely compatible with node. i was hoping node would just be made compatible with commonjs, but that's clearly not going to happen
[16:51] <deanlandolt> tlrobinson: jack mostly works on node using kris's jsgi-node promised-fs adapters
[16:51] <deanlandolt> i've been doing some checkins now to work out the rest
[16:52] <tlrobinson> does all of jack work? like the file middleware, etc?
[16:52] <deanlandolt> static middleware does IIRC
[16:52] <deanlandolt> but it'll take some elbow grease to get the rest of the way...
[16:52] <tlrobinson> i also want to include jsgi-client or something like it in jack
[16:53] <deanlandolt> ah, that'd be a good dep
[16:53] <nrstott> deanlandolt, what about multipart form processing (it saves temp files...). Is that worked out?
[16:53] <tlrobinson> (basically i want the 3 line proxy server to work out of the box :)
[16:53] <deanlandolt> it diverges for node and rhino
[16:54] <deanlandolt> i could add a node handler using jsgi-node to jack so it could work out of the box
[16:55] <deanlandolt> but jsgi-node shouldn't be a dep, so it won't /quite/ work out of the box
[16:56] <tlrobinson> why shouldn't jack/handlers/node not be another included module?
[16:56] <deanlandolt> it can be...should we just include the whole of jsgi-node there?
[16:57] <tlrobinson> sure if you guys are cool with that. the less friction to people getting started with jsgi on any platform the better
[16:59] <tlrobinson> i was talking to kriskowal about the promises issue, it sounds like we could have a jack/promise module that has a consistent public API (the "Q" API i guess) that works for both kriskowal and kriszyp's promises
[16:59] <deanlandolt> cool...i don't think it'd be a big deal -- just makes jack less modular
[16:59] <deanlandolt> we could, yeah...but that's kinda tough to spec, isn't it? (you want to use JSGI? you MUST use this module)
[17:01] <tlrobinson> so my thought was that jack would use that module internally, and once you have use promises in your code you have to make sure you either use jack/promise or a compatible promise implementation
[17:01] <tlrobinson> so we could at least swap the implementations internally easily
[17:02] <tlrobinson> does that make sense
[17:02] <tlrobinson> its mostly a stopgap until commonjs decides on the one true promise implementation
[17:02] <deanlandolt> it does but it still seems hard to say what a promise is
[17:02] <deanlandolt> but will it ever? can it?
[17:03] <tlrobinson> it has to
[17:03] <deanlandolt> i get the benefits of the Q API -- it's certainly the direction tc-39 has been going (don't piss in the namespace pool)
[17:03] <tlrobinson> promises are less useful if you have multiple incompatible implementations of promises
[17:03] <deanlandolt> but is that even the purview of commonjs? i thought it was about specs and interoperable implementations -- not One True implementation?
[17:04] <deanlandolt> i thought the idea was multiple compatible implementations though
[17:04] <tlrobinson> err i meant interface
[17:04] <tlrobinson> implementation doesn't matter
[17:05] <deanlandolt> aye, but that's the rub w/ Q -- opaque objects require /one/ implementation to be interoperable
[17:05] <deanlandolt> requires an instanceof and all that
[17:05] <tlrobinson> one implementation per system
[17:05] <deanlandolt> what if you're in a sandbox?
[17:06] <tlrobinson> thats like saying there must be one implementation of String
[17:06] <deanlandolt> and what you require is no longer the *same* jack/promise
[17:06] <deanlandolt> but nobody designs apis aren't instanceof for string, right?
[17:07] <deanlandolt> s/aren't/around
[17:08] <deanlandolt> if you instanceof String in a sandbox you'll get screwed, right?
[17:09] <tlrobinson> i don't know, i don't particularly care about what promises look like, i just want everyone to decide on one so we can move forward, but that's not happening, so i'm trying to come up with a temporary solution for jack
[17:09] <deanlandolt> the same problem occurs if the Q module you get is a different instantiation from the promise you received, right?
[17:09] <deanlandolt> :)
[17:09] <deanlandolt> yeah, i think jack should always use "when", that way we'll always be interoperable no matter what
[17:10] <nrstott> what is the issue? 'when' works with kowal and zyp style promises right?
[17:10] <tlrobinson> you mean they should use the promise manager? Q?
[17:10] <deanlandolt> if jack avoids any notions of "then" (which it has to do anyway because JSGI allows folks to return types as well as promises) it's no big deal for jack or jsgi
[17:10] <deanlandolt> tlrobinson: yes, they should use /some/ promise manager
[17:10] <deanlandolt> but i don't think jsgi can spec that :-/
[17:11] <tlrobinson> right, that's the idea, jack/promise would be a promise manager that works with whatever promises thrown at it
[17:11] <deanlandolt> gotcha
[17:11] <nrstott> so jack/promise would have the 'when' method?
[17:11] <deanlandolt> so we'll just roll zyp's promise implementation into jack/promise -- it's a superset of kowal's
[17:11] <tlrobinson> i guess so, i haven't thought it through completely
[17:11] <deanlandolt> nrstott: yeah...var Q = require("jack/promise")
[17:11] <tlrobinson> i think it would have the whole Q API, yeah
[17:12] <nrstott> why do we call it Q? that sounds awful to me :)
[17:12] <deanlandolt> heh -- you can call it anything you want
[17:12] <deanlandolt> var when = require("jack/promise").when // this is what i'd do
[17:12] <nrstott> is the idea that since the event-queue is behind all of this that we are cute and call it Q
[17:12] <tlrobinson> there should be a convention, at least in the jack source
[17:12] <deanlandolt> yeah, but we don't really need to require anything but when, right?
[17:12] <nrstott> deanlandolt, shouldn't
[17:13] <deanlandolt> so we can't sidestep that little issue completely :)
[17:13] <nrstott> yay
[17:13] <nrstott> im not a naming nazi, just was an observation
[17:13] <deanlandolt> there's one other issue...
[17:13] <deanlandolt> jack should use whenPreservingTypes whenever possible :-/
[17:13] <nrstott> also, it appers that the coding standard of using uppercase for module names is not catching on in the node world... or in pinture/perstore
[17:14] <deanlandolt> meaning, by default when always returns a promise...that's not right for jack because it'll screw up sync jsgi apps that just want to use one of jack's mw elements
[17:15] <nrstott> what is the point of whenPreservingTypes over just when
[17:15] <deanlandolt> when always returns a promise, even if it receives a non-promise
[17:15] <nrstott> when is supposed to be the answer to the 'sync'/'async' divide
[17:15] <deanlandolt> well, it bridges the divide on the inbound side...what comes out is always a promise :-/
[17:15] <tlrobinson> i originally thought when was supposed to behave like whenPreservingTypes
[17:15] <deanlandolt> whenPreservingType is the answer
[17:15] <tlrobinson> but i guess not
[17:15] <deanlandolt> yeah, so had i
[17:16] <deanlandolt> i'm not sure what the status on that was
[17:16] <tlrobinson> needs a better name
[17:16] <nrstott> so does whenPreservingType block?
[17:16] <deanlandolt> yeah...any ideas?
[17:16] <tlrobinson> no
[17:16] <deanlandolt> no, it doesn't /block/ per se -- it returns a promise if it gets one, it returns a value if it gets one of those
[17:16] <deanlandolt> wait blocks...but i think that's been roundly abandoned
[17:18] <nrstott> so how would whenPreservingType make async middleware usable by sync consumers?
[17:19] <nrstott> or am I missing the point?
[17:19] <nrstott> I'll BRB
[17:19] <deanlandolt> nrstott: it doesn't...it makes jack's middleware usable by both async and sync consumers
[17:20] <nrstott> deanlandolt, that implies to me that jack's middleware is all sync?
[17:20] <nrstott> cause if you are passed a promise, whenPreservingType is still going to give you back a promise
[17:20] <deanlandolt> that's the beauty of whenPreservingType (or some better name :))...
[17:20] <deanlandolt> it can be used by both sync and async apps
[17:20] <deanlandolt> yes, which means it can be used by async apps
[17:21] <nrstott> ok, if i have an async file server middleware... its always going to give me a promise back meaning whenPreservingTypes is going to return a promise meaning itg can't be used by sync
[17:21] <nrstott> I must be missing something
[17:21] <deanlandolt> nrstott: the file server isn't really middleware at that point -- it's generating a response
[17:22] <deanlandolt> now, say you have content-length middleware (per jack)...
[17:22] <deanlandolt> you could plug that into a sync app or an async app and it'll just do what it's supposed to do
[17:22] <nrstott> my fileserver may be middleware, it may only generate part of the body
[17:23] <nrstott> some other middleware may process that body and do something with it
[17:23] <nrstott> or may append to it or add to the front
[17:23] <nrstott> prepend*
[17:23] <nrstott> basically taht's just not supported right ;0
[17:23] <deanlandolt> yes, then your fileserver will only work on async servers...no big deal
[17:24] <deanlandolt> or, you could inspect the request.jsgi.async var and branch on its value (returning sync if you must)
[17:38] <deanlandolt> tlrobinson: do you remember what sqeeze is supposed to do?
[17:38] <deanlandolt> err, String.prototype.squeeze
[17:41] <WesMac> You guys see the <?js .... ?> query in the newsgroup today? Remind me why inline tags a-la PHP/ASP/JSP are "bad"?
[17:41] <deanlandolt> :)
[17:42] <ondras> because you can do
[17:42] <ondras> <?php if ($...) { ?>
[17:42] <ondras> ...
[17:42] <WesMac> (that was a serious question, BTW; I like the idiom for many tasks, but find it hard to manage large projects that way)
[17:42] <ondras> <?php } else { ?>
[17:42] <ondras> ...
[17:42] <ondras> <?php } ?>
[17:42] <ondras> and that is very evul.
[17:44] <WesMac> ondras: I agree that construct is evil - and actually tricky to parse. I would want to see <?js .... ?> being complete code units
[17:44] <WesMac> In PHP, does it selectively emit HTML?
[17:44] <WesMac> like. between the braces?
[17:45] <ondras> it emits whatever you put there
[17:45] <ondras> or perhaps I don't understand your question?
[17:45] <WesMac> No, I think you understood and answered. THat's just UGLY man
[17:46] <WesMac> I would want to basically see
[17:46] <WesMac> XXXX <?js .... js?> YYYY
[17:46] <WesMac> where the content in the JS tag is a complete code unit, and MAY emit code between XXXX and YYYY via a print statement
[18:02] <WesMac> Has anybody looked at JSSP?
[18:03] <WesMac> For one, it looks like he's gone with "fast parser" instead of "smart parser", but I can't say I blame him
[18:04] <WesMac> i.e. <% out.print("%>"); %> is a syntax error
[18:05] <WesMac> His <%=expr %> syntax is handy. basically outputs (expr) + ""
[18:05] <WesMac> <OMMON %> is funny. It gets executed by the server and emitted inside a <SCRIPT/> tag toward the client. So it runs both locally and on the browser.
[18:06] <WesMac> That's <% COMMON %>, I don't know where the percent C went up there. Maybe chatzilla ate it?
[18:06] <WesMac> I guess <% COMMON %> is a reasonable way to define form validation code and stuff
[18:08] <WesMac> He doesn't support include files though: "they create lots of trouble like cyclic dependencies"
[18:09] <WesMac> we should introduce him to securable modules :D
[18:09] <WesMac> Oh, wait, he has libraries, though.
[18:51] <nrstott> what're you guystalking about, EJS?
[18:58] <WesMac> nrstott: No, JSSP
[18:58] <WesMac> What's EJS? That rings a bell
[18:59] <nrstott> <%= some_javascript_code %> templating
[18:59] <WesMac> Oh, that!
[18:59] <nrstott> http://github.com/nrstott/bogart has an example of its use
[18:59] <WesMac> Ouch, nice syntax collision, hope nobody tries to merge those two projects :D
[18:59] <deanlandolt> tlrobinson, nrstott: just so you know, i just checked out promise.js and added i'm adding it to jack...turns out that there is no more whenPreservingType -- when does that, and whenPromise instead always returns a promise
[19:00] <nrstott> and in node, someone land-grabbed the name 'EJS' in NPM for something that is totally not EJS
[19:00] <WesMac> argh, node should use UUIDs! :p
[19:00] <nrstott> somebody took resigs microtemplating, called it EJS, and ran with it
[19:00] <nrstott> when EJS is really far more complicated than that...
[19:01] <nrstott> im looking at the express folks on this one ;0
[19:05] <WesMac> nrstott: Have you given much thought to using ~ EJS to replace <?php?>, like in your EJS layout example in bogart?
[19:05] <WesMac> nrstott: I'm thinking about in something like an apache environment where we're transitioning from PHP
[19:08] <WesMac> It almost looks like it would "just work", at least from a syntax POV
[19:34] <WesMac> http://bit.ly/9v2Vb9
[19:35] <WesMac> wow, presentation includes a graphic of a unicorn riding a narwhal
[19:43] <WesMac> make that *two*
[19:52] <deanlandolt> tlrobinson: i'm pushing updates to jack to up the middleware to be 0.3-friendly and make it work with node...but i got detoured: http://github.com/deanlandolt/jack/blob/master/examples/statuscodedrinkinggame.js
[21:27] * Dantman started his own "EJS" project at one point
[21:27] <Dantman> Though, I wanted to do it using the narcissus parser...
[21:29] <Dantman> <%= arr.map(function(a) %>"<%= a %>"<% ).join(", "); %>
[21:30] <Dantman> Btw... ;) that supports something that doesn't work in ERB
[23:13] <deanlandolt> tlrobinson: there are definitely some places where jack's going to need to lean on something like promised-io...it's cool for that to be a dependency, right?
[23:14] <deanlandolt> if so, i'll just create an alias for its promise implementation at jack/promise

 

 

Logs by date :