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

2009-10-28:

[0:02] <kriskowal> looks like i've got a new install error. sending
[0:03] <kriskowal> in any case, flusspferd and juice appear to work, regardless of the install failure
[0:03] <ashb> yeah, the install failure is just adding htem to the path
[0:03] <ashb> which is probably already in hte path for the default install location
[0:09] <ashb> kriskowal: /usr/bin/printenv MANPATH
[0:09] <ashb> does that exit with 1?
[0:10] <kriskowal> 0
[0:10] <ashb> since this itme it seemed to get most of the way through
[0:10] <ashb> just failed at the setting manpath somewhere
[0:14] <ashb> maybe i should just remove the set -e for that part
[0:14] <kriskowal> would flusspferd have been spellt flu?pferd before the spelling reform?
[0:14] <ashb> MisterN: ^^
[0:14] <ashb> (i'm not german, despite the surname)
[0:14] <kriskowal> oh, no kidding.
[0:15] <kriskowal> well, i'm not polish, so it stands to reason
[0:15] <ashb> grandfather was, I dont speak beyond bad highschool german
[0:16] <kriskowal> it's great to have a packaged binary for this
[0:16] <kriskowal> building it is a pita
[0:16] <ashb> yeah.
[0:16] <evilstreak> don't we know it
[0:16] <evilstreak> packaging it is worse ._.
[0:17] <ashb> one of my aims for the first release was to make it as simple as possible to install
[0:18] <kriskowal> when i require("fs-base") in flusspferd cli, i get an empty object
[0:18] <ashb> thats a bug in the repr print
[0:18] <ashb> there's method on it
[0:18] <ashb> *s
[0:19] <kriskowal> i see. okay
[0:19] <ashb> feel free to point out any deviations from any of the spec :)
[0:21] <kriskowal> yeah, np.
[0:25] <ashb> and sleep
[10:00] <olivvv> hi. I'm really confused to see almost ALL server-side js projects using templating systems.
[10:00] <olivvv> Why is it so ?
[10:01] <olivvv> I dont get it, if the dom is available then it can be easily manipulated with js
[10:01] <evilstreak> because DOM manipulation isn't available outside of a browser by default
[10:02] <evilstreak> and because DOM manipulation can make for messy templating
[10:02] <evilstreak> but if you want a templating solution that uses DOM manipulation, checkout PURE
[10:02] <evilstreak> by someone in here (I forget who)
[10:02] <olivvv> ah so the dom is available only in jaxer currently ?
[10:03] <evilstreak> I don't know which implementations have a DOM at the moment
[10:03] <evilstreak> but I personally don't think that approach is the best way to go
[10:04] <evilstreak> you still need a template (i.e. the uncustomised HTML), and then in addition to that you need the instructions to manipulate it
[10:04] <evilstreak> whereas a template combines both those parts into one
[10:04] <olivvv> to me a template is much more poor than the dom. templates engine treat the dom as a string
[10:05] <evilstreak> what do you want to use the DOM for?
[10:05] <evilstreak> what problem are you trying to solve?
[10:05] <ashb> olivvv: so JavaScriptCore (safari's JS engine) is the only one of the big 4/5 that can actually get a useful dom without pulling the entire browser
[10:06] <evilstreak> ashb: that's ignoring the 3rd party implementations though
[10:06] <evilstreak> like libxml et al
[10:07] <olivvv> evilstreak: none, so I dont see why templates engines are a solution. Its easy to use a var to contain the "uncustomised HTML" and then play with it.
[10:07] <evilstreak> olivvv: but that's a two step process
[10:08] <evilstreak> "<h1>placeholder</h1>".find("h1").text(myText); vs: "<h1>[% myText %]</h1>"
[10:08] <evilstreak> and as you add more complexity the DOM manipulation method becomes very heavy
[10:08] <olivvv> HTML is our common language, tempates meta-languages are sectarian.
[10:09] <evilstreak> but as I say, there's a templating solution based around manipulating the DOM called pure
[10:09] <evilstreak> that might be more to your tastes
[10:09] <olivvv> I m looking at it
[10:10] <simono> evilstreak: yeah there is pure and i'm always pimping my own pureskin which is simpler ;)
[10:11] <simono> as i said before string-templating solutions seem really stupid to me, as they duplicate markup
[10:11] <evilstreak> duplicate how?
[10:11] <simono> like <h1> [% Heading %] </h1>
[10:12] <simono> why add additional markup-tags when html-tags are already in place. at least for clientside templating the dom approach feels a lot better to me
[10:12] <simono> but it's new territory for me too... we'll see earliest in a few month who it all fits together
[10:12] <olivvv> simono: nice to see that I'm not alone in my anti-templates stance.
[10:13] <olivvv> evilstreak: it seems that pure is more a convention than an engine, am I right ?
[10:13] <simono> olivvv: in a way
[10:13] <evilstreak> personally I prefer haml's syntax anyway: %h1= heading
[10:14] <simono> olivvv: i don't like pures loop syntax, i redid them as explicit loops.. no magic
[10:14] <evilstreak> way cleaner than even pure html
[10:14] <simono> evilstreak: i should try haml, looks good too
[10:15] <sfoster> I'm using dojo's dojox.dtl - a django template language implementation
[10:15] <simono> ah.. i seen another django-templating in js on googlecode
[10:15] <sfoster> there's supposedly a commonjs implementation also, though I've not seen it
[10:15] <simono> another benefit of pure/pureskin: you can attach behaviour as well
[10:16] <evilstreak> not from the server, but on the client yes
[10:17] <evilstreak> though if you use event delegation (i.e. $.live instead of $.click) then you end up needing to attach behaviour on the fly a lot less often
[10:17] <olivvv> "dojo's dojox.dtl - a django template language implementation" --> see, that feels immediately sectarian
[10:18] <simono> $.live is a safer sometimes.. but you end up defining your behaviour far away from the actual template
[10:19] <ashb> as you should anyway
[10:19] <ashb> behaviour shouldn't really be tied all that closely to presentation
[10:19] <simono> it's presentation code
[10:19] <ashb> depends what it is i guess
[10:20] <simono> right, think so too
[10:24] <evilstreak> the biggest problem with HTML and DOM manipulation as a templating language (I think) is that you are coupling your view and controller too tightly
[10:24] <evilstreak> since you are effectively using selectors as keys for filling the template instead of abstracting the keys to things like [% header %] and [% username %]
[10:26] <simono> that is not perfect, but selectors (usually extra css classes with a certain prefix) seem better to me than the additional tags
[10:27] <simono> i don't see how it's related to the controller. there is the view, the presentation model (behaviour), the controller, the model
[10:28] <evilstreak> in theory your controller generates a bunch of data and passes it off to the view which renders it
[10:28] <ashb> yeah, i guess the data -> selector could be in a view.js or similar
[10:28] <simono> hold on ;)
[10:28] <ashb> simono: anyway - we're making the template system in Jucie pluggable right now
[10:28] <simono> controller on the clientside is stuff that goes in onclick, etc
[10:28] <ashb> we're not talking client side here
[10:29] <simono> ashb: nice
[10:29] <evilstreak> either you are passing that data over already tied to selectors in which case you have coupling, or you have an extra step to tie that data to the relevant selectors
[10:29] <simono> oops, i am. there is no view code with behaviour attached on the server for me
[10:29] <evilstreak> oh
[10:29] <ashb> simono: the current interface is basically templates = { '.ext': module_name }
[10:29] <evilstreak> talking cross purposes
[10:29] <simono> sorry, wasn't talking juice specifically
[10:29] <evilstreak> olivvv was wondering why hardly any server JS implementations use DOM manipulation for templating
[10:30] <simono> yeah i got that. i think doing templating serverside is sometimes necessary but should be avoided :) but that viewpoint is extreme
[10:31] <ashb> see i'd go the other way - i'd use templates on the client for certain kinds of app
[10:31] <ashb> how else do you generate large chunks of new html?
[10:31] <simono> yes for certain kinds of app..
[10:32] <evilstreak> I think loading in unpopulated HTML snippets from external files and then filling them with content might be the way to go client-side
[10:32] <simono> evilstreak: think so too
[10:32] <evilstreak> templating abstractions are probably overkill a lot of the time
[10:32] <simono> e.g. for a twitter client..
[10:32] <evilstreak> especially for simple things like inserting a site search widget dynamically or some such
[10:33] <simono> what do you mean with "templating abstractions"
[10:33] <evilstreak> haml, template toolkit, etc
[10:34] <simono> ah okay
[10:34] <simono> well lots of different ideas.. i think that means templating will hopefully change a lot in the future :)
[10:34] <evilstreak> I think so
[10:35] <evilstreak> and I think people will continue to use what's good for them
[10:47] <olivvv> server-side js selling points is that js is kinda the common glue that everybody knows, isn't ?
[10:47] <ashb> that and you can reuse code between client and server
[10:47] <olivvv> to me, it is the same with html
[10:48] <olivvv> to reuse code between server and client effectively, I definitly need the dom server-side
[10:48] <ashb> yeah, theres all sort of useful tricks you can do with that
[10:49] <ashb> i just dont personally think DOM templating is right
[10:49] <ashb> but i do plan on getting a working portable dom
[10:49] <evilstreak> I want a DOM on the server
[10:49] <evilstreak> but for parsing not rendering
[10:49] <evilstreak> I want to use it with a selector engine like Sizzle to scrape content from sites that don't have APIs
[10:49] <ashb> i should look at that project humbletim was talking about
[10:50] <olivvv> And my js code should be easy to read, a newbee should not have to be scared by custom syntax stuff
[10:50] <evilstreak> templates are, by their nature, easy to understand
[10:50] <evilstreak> a newbie wouldn't be scared by seeing <h1>[% header %]</h1>. it's pretty obvious what that's doing
[10:50] <ashb> templates are designed to be able to be written by crap html monkies
[10:50] <evilstreak> oi, I'm one of those
[10:50] <ashb> you aren't a crap one
[10:51] <evilstreak> the simpler the templating language the better IMO, since otherwise there's a temptation to shunt work into the templates that should be done by the controller
[10:53] <olivvv> evilstreak: I should show you some smarty code after 5 years of an app life
[10:53] * simono finds controller confusing .. rails et al use it strangely. controller = mouse / keyboard / user input
[10:53] <olivvv> its totally ugly and custom
[10:53] <ashb> they way we use controller comes from MVC
[10:54] <simono> i know MVC from games, its very different from how web frameworks talk about it
[10:54] <olivvv> Anyway, interesting talk guys, I'll be back after lunch.
[10:54] <frodenius> hf
[10:54] <simono> template needs to worry about the presentation code which has nothing to do with the model
[10:55] * simono lunching
[10:55] <simono> but talking about MVC terminology will open another can of worms
[11:02] <ashb> of course - a good template system should be able to render itself down to a js function
[14:17] <deanlandolt_> ashb: congrats on juice!
[14:17] <ashb> deanlandolt_: thanks!
[14:17] <deanlandolt_> i'm going to download and play today...i'm also going to finish updating the jsgi 0.3 draft 2 :)
[14:17] <JohnnyL> ashb it's released?
[14:17] <ashb> JohnnyL: http://juicejs.org
[14:17] <JohnnyL> yay!
[14:20] <JohnnyL> ashb looks awesome. What about multi cpu/multi processor support?
[14:20] <ashb> JohnnyL: of what form?
[14:20] <JohnnyL> or is each request a seperate process?
[14:20] <JohnnyL> ashb ?
[14:20] <ashb> oh i see
[14:20] <ashb> right now the dev server is single process, single thread :)
[14:21] <ashb> Release early and Release Often
[14:21] <evilstreak> unless the dev server is going to become a production server, solving those issues may not ever be worthwhile
[14:22] <ashb> JohnnyL: for next release (or maybe the one after depending on when we do them)
[14:22] <ashb> we'll have a fastcgi module
[14:23] <Wes--> ashb: is zest a traditional UNIX forking daemon?
[14:24] <ashb> nope, its built on the boost asyncio framework
[14:24] <ashb> so its async everywhere outside of JS space currently
[14:25] <ashb> and i've been thinking about making it transparently async in suitable places too, like say the http-fetch module to not block incoming requests etc
[14:26] <ashb> isaacs_: http://juicejs.org you said you wanted to play, right?
[14:30] <JohnnyL> ashb ok
[14:36] <deanlandolt_> ashb: how do i get that fancy script/console on windows? flusspferd script\server works nicely but flusspferd script\console just exits
[14:36] <ashb> deanlandolt_: the flusspferd in front shouldn't be needed
[14:37] <deanlandolt_> ooooh
[14:37] <deanlandolt_> nice
[14:37] <ashb> we built batch files that to crazy env var parsing :)
[14:37] <ashb> *env line
[14:37] <deanlandolt_> yeah, i saw some of that conversation in the logs
[14:37] <deanlandolt_> kickass
[14:37] <ashb> which works better than env does on linux, cos the unix spec for env FUCKING SUCKS
[14:38] <ashb> or shebang parsing rather
[14:38] <deanlandolt_> yeah -- that's what i gathered
[14:38] <deanlandolt_> ancient specs are fun :)
[14:38] <ashb> #!/usr/bin/env a b c -> $(which a) "b c"
[14:38] <deanlandolt_> yeah, seems a bit silly
[14:38] <ashb> what with the fact we have a perfectly usable " key right there next to enter
[14:39] <deanlandolt_> heh
[14:39] <ashb> not quite sure how i'm actually going to work around that for linux yet
[14:39] <ashb> other than maybe move handle it in flusspferd
[14:39] <ashb> if the first line (that isn't a shebang) has say: //flusspferd-opts: -i
[14:39] <ashb> or similar
[14:40] <deanlandolt_> way over my head
[14:40] <ashb> yeah, dont worry about it :)
[14:40] <deanlandolt_> all that stuff just makes me happy i don't do sysadmin stuff :)
[14:46] <ashb> http://www.mail-archive.com/bug-bash@gnu.org/msg03970.html people like that piss me off
[14:46] <ashb> no it wouldn't since the current behaviour would be the same
[15:54] <JohnnyL> ashb will juice be multiprocess or multithread enabled? (will you make it stackless?)
[15:54] <ashb> juice itself is pure JS
[15:54] <JohnnyL> ah ok
[16:07] <afonso> is there any relational database ready to be used that doesn't rely on non-volatile memory? :)
[16:07] <afonso> i've foind JsonSQL but it isn't relational
[16:07] <afonso> *found
[16:11] <MisterN> afonso: sqlite.
[16:11] <MisterN> afonso: use the :memory: database.
[16:17] <afonso> ups, i wasn't very explicit, i was thinking a js-based one to run on the browser:)
[16:34] <MisterN> afonso: oh. well...
[16:34] <afonso> :D
[16:34] <MisterN> afonso: why do you need such a crazy thing?
[16:35] <afonso> i need to store data and the browser i'm using doesn't support html5 sql
[16:36] <afonso> (yet, at least)
[16:37] <inimino> afonso: you are limited to cookies and such, then, no?
[16:38] <afonso> yes, I am
[16:38] <afonso> but this is a opera unite service so I actually have access to the file i/o
[16:39] <afonso> still very raw access
[16:39] <inimino> ah
[16:39] <afonso> but enough to dump json for instance :)
[16:40] <afonso> i guess i'll do my own, i was just wondering if i was rebuilding the wheel (yeah, in a way i am)
[16:43] <ashb> afonso: couchdb?
[16:43] <ashb> oh relational
[16:43] <evilstreak> also, in the browser
[16:43] <ashb> couchdb has a REST API
[16:43] <ashb> so its not inbrowser, but accessible from browser
[16:44] <afonso> yeah, that was the first one I saw, but like you said, it's not relational :(
[16:44] <afonso> i guess I should use some paid service, but i'm cheap :P
[22:26] <ashb> so - doc systems then
[22:26] <ashb> anyone have any preferences?
[22:28] <Dantman|sick> *cough* doctest *sickcough*
[22:28] <ashb> Dantman|sick: which one?
[22:29] <ashb> also must be able to bake down to actual files on disk
[22:29] <ashb> well, for preference, i can add that if its good enough
[22:30] <Dantman|sick> Doctest, ie: testable js shell Rhino swiped from Python
[22:31] <ashb> can yo wite actual prose with it?
[22:32] <Dantman|sick> http://github.com/dantman/monkeyscript.lite/blob/master/tests/blob.doctest
[22:32] <ashb> is that a no then?
[22:33] <Dantman|sick> prose?
[22:33] <ashb> written or spoken language in its ordinary form, without metrical
[22:34] <ashb> structure
[22:36] <ashb> i.e. words and sentences
[22:36] * Dantman|sick wonders if he could learn enough Japanese to speak with while ill since he seams to have issues with English
[22:36] <kriskowal> doctest can be mixed with prose
[22:37] <kriskowal> really, doctest can be mixed with almost any other markup
[22:37] <ashb> ah but doctest itself is just it looks for certain things and runs them as test
[22:37] <Dantman|sick> Scrap that, I'm just bad at relating code and human language together
[22:37] <ashb> in which case cool idea, but not helpful to me right now
[22:37] <ashb> (if i get what it is)
[22:38] <ashb> but for some reason i never seem to get on very well with JsDoc Toolkit
[22:38] <Dantman|sick> That's one of the things about ruby that annoys me
[22:38] <Dantman|sick> I like my conversations in English, and my programming in code... (except of course when making programming jokes)
[22:40] <ashb> also jsdoctk has horrible cmnd lin arg handlin
[22:40] <ashb> -d=out
[22:40] <ashb> i mean come on
[22:40] <kriskowal> these things can be fixed.
[22:40] * ashb might be irrationally anooyed with it right now
[22:41] <kriskowal> my args module has a special decorator for that.
[22:41] <kriskowal> .input() or .output() make options that take a file name or "-" as an alias for stdin or stdout respectively
[22:42] <ashb> -d out just doesn't process the arg
[22:42] <ashb> it needs it as -<letter>=<value>
[22:42] <kriskowal> oh
[22:43] <kriskowal> yeh, i went with the gnu convention, mimicking the most recent python option parser
[22:43] <ashb> yeah - same with flusspferd
[22:43] <ashb> --long=value or -s value
[22:43] <kriskowal> e.g., cut -d. -f1,2,3 works
[22:43] <kriskowal> yeah, also --long value and -svalue
[22:45] <ashb> part of my problem might just be 1) i'm triyng to document the native modules (i.e. ones without a .js to parse)
[22:45] <ashb> and 2 i'm too used to the more free-form POD from perl
[22:47] <ashb> 3) i'm not sure jsdoc really works well with the modules paradigm
[22:49] <ashb> am i just being picky?
[23:04] <MisterN> ashb: -svalue works too
[23:05] <ashb> in flusspferd, yeah
[23:08] <MisterN> in GNU, too.
[23:08] <ashb> okay i'm having serious failure with JSdoc toolkit
[23:09] <ashb> http://pastie.textmate.org/674183
[23:09] <ashb> produces no output
[23:10] <ashb> oh!
[23:10] <ashb> its the -S (securable modules) option
[23:11] <ashb> see. this is my problem with jsdoc. it tries to examine the code and it never behaves how i expect
[23:25] <ashb> so right now i think i'm favouring a more free-form wiki based version
[23:25] <ashb> s/version/doc system/

 

 

Logs by date :