Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-07-27:
[7:01] <hannesw> good morning #ringojs[7:15] <zumbrunn> good morning :-)
[7:20] <gmosx> hi every1
[7:21] <weiht> hannesw: Got a question here. Is there a way to wrap the request parameters such like 'obj.prop' to request.params.obj.prop, before the action executes?
[7:21] <hannesw> weiht: yes
[7:22] <hannesw> you can use obj[prop] syntax and the request parameter parser will do that for you
[7:22] <hannesw> also obj[] for arrays (i think)
[7:23] <hannesw> another thing that needs to be documented - i linkified the terms on this page: http://ringojs.org/wiki/Web_Framework/
[7:24] <hannesw> good morning zumbrunn gmosx
[7:27] <weiht> hannesw: And deeper, as 'login.password.hash'?
[7:27] <hannesw> yes, it should all work
[7:27] <hannesw> this is not well tested (or documented) though
[7:27] <weiht> hannesw: Thanks.
[7:27] <hannesw> weiht np
[7:28] <weiht> hannesw: I don't know the meaning of 'np'...
[7:28] <hannesw> no problem = you're welcome
[7:29] <weiht> hannesw: OK, thanks a gain.
[7:30] * gmosx is packing his stuff...
[7:32] <hannesw> so, I'll kick of the IRC meeting by saying that we have to get ringojs out of mid-summer snooze mode
[7:32] <hannesw> :)
[7:34] <hannesw> a big cause for indecision for me has been thinking about restructuring standard modules
[7:35] <hannesw> 1) thinking about the core/* modules (evil/not evil)
[7:35] <hannesw> 2) thinking about what may be missing
[7:36] <hannesw> 3) thinking about what may be too much, and should be in separate modules (webapp? skins? storage?)
[7:36] <hannesw> so, waiting for everybody's input on these issues :)
[7:37] <zumbrunn> I still think ringo should, at its core, be as lean as possible
[7:38] <zumbrunn> instead of splitting stuff out into separate "projects", that could also mean adding different build targets
[7:38] <gmosx> core/* is evil
[7:39] <gmosx> skins + storage should be split off...
[7:39] <hannesw> zumbrunn the build targets idea is interesting
[7:39] <gmosx> modules should be renamed to lib, lib to jars
[7:39] <gmosx> and we should add a couple of helpers from narwhal-lib ;-)
[7:39] <gmosx> that's my wish list for the next version :)
[7:40] <hannesw> gmosx I largelely agree about core/*
[7:40] <hannesw> but then i looked at things like array.peek() which is just really nice to have
[7:40] <gmosx> how about ArrayUtils.peek() ?
[7:40] <hannesw> well narwhal's Hash could replace our Object.merge(), for example
[7:41] <gmosx> one idea would be to introduce a ringo/utils directory or something similar...
[7:42] <zumbrunn> ideally, at the leanest level, ringo could be a "better rhino"
[7:42] <zumbrunn> "better rhino" == ability to embed ringo as a js engine in place of rhino
[7:42] <hannesw> gmosx +1 for ringo/utils/* (or ringo/util/*)
[7:43] <hannesw> zumbrunn right, that's what ringo should be in the first place
[7:43] <gmosx> zumbrunn: +1
[7:43] <hannesw> so does that mean ringo should come without jetty and without webapp modules?
[7:43] <gmosx> on a related note, I think you should remove the Js from the logo...
[7:43] <zumbrunn> well, it could offer such a buid target
[7:44] <gmosx> keep it in the domain name onlue...
[7:44] <hannesw> or should we do two "distributions", like ringo-core and ringo-full
[7:44] <gmosx> I think it should be rhino only...
[7:44] <gmosx> and webapp and the rest could be installable modules...
[7:44] <zumbrunn> rhino only?
[7:44] <gmosx> ringo only
[7:44] <gmosx> maybe include the webapp package by default...
[7:45] <zumbrunn> gmosx: http://ringojs.com/bot/rhinojs :-)
[7:45] <hannesw> zumbrunn build target is just one thing, it's also about how you distribute, and what's in the repository
[7:46] <zumbrunn> I guess there are "three ringos"
[7:46] <zumbrunn> 1) the better rhino for embedding
[7:46] <zumbrunn> 2) the js scripting env with shell
[7:46] <zumbrunn> 3) the web framework
[7:46] <zumbrunn> maybe 1) and 2) are the same
[7:47] <hannesw> zumbrunn yes, agreed. so there's basically ringo-core and ringo-with-webapp
[7:47] <hannesw> and maybe webapp should only be real web stuff, but not storage + templating?
[7:47] <zumbrunn> right
[7:48] <zumbrunn> yes
[7:48] <hannesw> because people will need parameter parsing etc, but tastes for storage and templating may differ
[7:50] <hannesw> ok
[7:50] <hannesw> so how do we organize this from a repository/build point of view?
[7:50] <hannesw> either, as zumbrunn suggests, just different build targets, or we split webapp into its own repo and add a build target that fetches and bundles it...
[7:52] <zumbrunn> separate repos are ultimately probably the cleaner solution?
[7:52] <zumbrunn> but I don't really have a preference on that
[7:52] <hannesw> zumbrunn yes
[7:55] <hannesw> well that will bring about quite a bit of change (and breakage)
[7:55] <hannesw> would be interesting to hear other opinions
[7:56] <zumbrunn> yes
[7:56] <hannesw> ping earl rist robertgg robi42 waddler -^
[7:57] <robi42> imho, splitting ringo up into separate, well-defined parts would be preferable. yet, not really an idea what would be best approach here.
[7:58] <hannesw> one issue i see is that current package management may not be robust enough for this
[7:58] <gmosx> webapp should be a separate module...
[7:58] <gmosx> sorry gotta go...
[7:58] <gmosx> l8rz...
[7:58] <hannesw> gmosx, cu
[7:59] <hannesw> maybe we should have an "official" package repository for core packages like webapp etc
[7:59] <hannesw> that has some versioning support
[7:59] <robi42> sounds reasonable
[8:00] <hannesw> for example ringo 0.6 will install package "ringo-webapp" from packages.ringojs.org/releases/ringo-webapp/0.6/
[8:00] <hannesw> instead of going to github
[8:02] <hannesw> well it's another maintainance job... nice thing about github is that maintainance is free
[8:02] <zumbrunn> :-)
[8:02] <hannesw> or we could just use github + tags
[8:03] <robi42> github + tags would suffice, wouldn't it?
[8:03] <hannesw> so if i install package "ringo-webapp", it goes to github.com/ringo/ringo-webapp/tags/0.6/zipball
[8:03] <hannesw> or whatever the url is
[8:03] <hannesw> robi42 yes, i think it would
[8:07] <hannesw> ok, i think this might work
[8:07] <hannesw> one problem that remains with github is packages that require a build (e.g. compiling java classes)
[8:08] <hannesw> looks like we just have to avoid that if we want to go github as package repository
[8:12] <hannesw> robi42 zumbrunn what is your take on the core/* modules?
[8:12] <hannesw> (sorry if we've had that before...)
[8:13] <hannesw> compatibility > convenience?
[8:13] <zumbrunn> I have no problems with what we have
[8:13] <zumbrunn> but I understand that others do
[8:13] <zumbrunn> and it's fine to accommodate for that
[8:14] <robi42> +1 zumbrunn
[8:14] <hannesw> ok
[8:15] <hannesw> how should we go about these changes? branch on the main ringo/ringojs repository?
[8:15] <robi42> so i'm fine with putting core protoype extensions into dedicated util(s) modules
[8:15] <robi42> +1 for branch
[8:16] <hannesw> so i guess also ringo/fileutils will become ringo/utils/file, right?
[8:16] <robi42> yep
[8:16] <hannesw> what with current ringo/utils?
[8:16] <robi42> ringo/utils/base ?
[8:17] <hannesw> or might be split up... it's a hodgepodge anyway
[8:17] <hannesw> format -> ringo/utils/string
[8:18] <hannesw> then there's two stack trace rendering utilities..
[8:18] <hannesw> and those property descriptor utils which i think are not used anymore
[8:18] <hannesw> by ringo itself
[8:18] <robi42> ringo/utils/logging for the former?
[8:18] <hannesw> yes, maybe
[8:19] <hannesw> ok, things are getting clearer :)
[8:21] <hannesw> afk for 5 minutes
[8:24] <zumbrunn> do we already have a way to load modules from somewhere other than the file system?
[8:24] <zumbrunn> like from inside a storage implementation
[8:33] <hannesw> zumbrunn no, but anything that implements repository/resource java interfaces would work
[8:33] <zumbrunn> ok, good to know
[8:34] <hannesw> you'd like to have code in a db?
[8:34] <zumbrunn> I was thinking about the scenario of replacing rhino in sling with ringo
[8:34] <hannesw> hm ok
[8:35] <zumbrunn> which would mean the modules path for apps would need to point into the jcr repository
[8:35] <hannesw> no idea about sling internals
[8:35] <hannesw> ok, should be doable
[10:44] <hannesw> started core -> utils branch...
[12:41] <hannesw> hm, one problem with moving methods off the core prototypes is the conflict between keeping names short and making them self-explanatory
[12:42] <hannesw> for example, Array.prototype.contains is fine, because you use it as array.contains()
[12:43] <hannesw> but when you require it as unbound function, "contain" looses the connotation that it's supposed to be used on arrays...
[12:43] <hannesw> we need some kind of "best practice" there
[12:43] <hannesw> many options...
[13:18] <mcepl> are there somewhere source packages for the Debian packages on http://github.com/ringo/ringojs/downloads ?
[13:18] <mcepl> sorry, i am blind
[14:09] <hannesw> mcepl we only have binary packages up there
[14:10] <mcepl> yeah, but git checkout has debian/ subdirectory
[14:10] <mcepl> (I was too long in the rpm world ... ;))
[14:11] <mcepl> *have been
[14:11] <hannesw> if you have debian build tools installed, you can build with dpkg-buildpackage
[14:11] <hannesw> dpkg-buildpackage -rfakeroot
[14:11] <hannesw> i think
[14:12] <hannesw> there's also an ant task for it:
[14:12] <hannesw> ant dpkg
[14:19] <mcepl> no, I want to make proper Fedora package and i was looking for an inspiration where to put what
[14:20] <mcepl> actually, is it possible to persuade ringo to look more possible directories (e.g., /usr/share/ringojs/packags:/usr/local/share/ringojs/packags:$HOME/.ringojs/packages)?
[14:21] <hannesw> mcepl yes, that should be possible
[14:21] <mcepl> where should I start?
[14:22] <hannesw> look at modules/packages.js
[14:22] <hannesw> it provides functions to add packages directories
[14:25] <mcepl> thanks
[15:03] <earl> mcepl: while you are at it, you can also use saner directories for the fedora packages :)
[15:04] <earl> for example, /usr/share/ringojs/packages should rather be /usr/lib/ringojs/packages
[15:05] <earl> we'll get around to fix this for the debian packages as well, eventually
[15:05] <mcepl> that's questionable .. ./usr/share is for non-archi specific code
[15:06] <mcepl> and ringojs is just .jars and .jss isn't it?
[15:06] <mcepl> *.js files
[15:06] <earl> share is for data, not code
[15:06] <mcepl> that's not Fedora Packaging Guidelines opinion
[15:07] <earl> well, that's only according to the FHS
[15:07] <earl> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
[15:08] <earl> if fedora does things differently, it's probably better to adhere to fedora conventions
[15:09] <mcepl> don't argue with me, argue with Fedora Board or somebody like that ;) ... meanwhile I will package ringojs so that it has a chance to get to Fedora ;)
[15:10] <earl> where's e.g. python's urllib.py located on fedora?
[15:16] <mcepl> We don't split packages in half and python contains arch-specific files so it is in /usr/lib64/python2.6/urllib.py
[15:40] <mcepl> OK, bad luck ... I don't have org.eclipse.jetty.continuation in RHEL :(
[15:41] <mcepl> and full jetty requires half of the maven to be built :(
[16:19] <mcepl> OK, bad luck ... I don't have org.eclipse.jetty.continuation in RHEL and full jetty requires half of the maven to be built :(
