Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-08-24:
[6:59] <hannesw> good morning[6:59] <hannesw> have to get some coffee
[7:06] <hannesw> set up agenda for today's irc meeting: http://ringojs.org/wiki/IRC_Meeting/
[7:06] <hannesw> please feel free to add your own issues
[7:07] <oberhamsi> maybe the response refactor stuff from robi
[7:08] <hannesw> right
[7:09] <hannesw> ok, added that as well
[7:09] <hannesw> let's start with that, ok?
[7:10] <hannesw> so is anybody not happy with the new response helper functions, and prefers the old way?
[7:11] <hannesw> i guess not :)
[7:11] <hannesw> I have a working module.resolve() in my local working copy
[7:11] <hannesw> it returns the relative path to a resource so it can be fetched via getResource()
[7:12] <hannesw> so it will work with resourses in zip files or webapps
[7:13] <oberhamsi> cool, do you want to put that in 0.6 or does it need more test/work?
[7:13] <hannesw> no, it's quite safe
[7:14] <hannesw> the one thing i'm unsure is behaviour of module.directory for zipped or webapp resources
[7:14] <hannesw> it's not really helpful i guess...
[7:15] <hannesw> for zip resources it's /dir/file.zip!resource/path
[7:15] <hannesw> and for webapps it's /WEB-INF/resource/path i think
[7:16] <hannesw> so that's not really a directory... but better leave it as it is for 0.6
[7:18] <hannesw> ok, next issue?
[7:19] <hannesw> remaining module cleanup: ringo/utils
[7:19] <hannesw> i talked about that with orf.at folks
[7:19] <hannesw> the idea is that things in ringo/utils could be split up to ringo/utils/strings, ringo/utils/objects, etc
[7:20] <hannesw> there's not really a lot in there that must be in a "top level" ringo/utils
[7:20] <hannesw> http://ringojs.org/api/master/ringo/utils
[7:21] <hannesw> for example, the *PropertyDesc functions are pretty esoteric.
[7:21] <hannesw> i think they could be either moved to ringo/utils/objects, or dumped
[7:21] <hannesw> oberhamsi do you remember the conclusion we came to on this?
[7:21] <robi42> maybe the get*Stack stuff could go into some ringo/utils/logging module?
[7:22] * oberhamsi looks at api to remember
[7:22] <hannesw> robi42 right, i think we had the same idea
[7:22] <oberhamsi> robi42, right!
[7:22] <hannesw> damn, gotta take notes next time :)
[7:23] <oberhamsi> propertydesc stuff to objects and format() to strings me thinks
[7:23] <hannesw> propertydesc doesn't really belong in strings though. I'd say objects
[7:23] <hannesw> format in strings is fine
[7:24] <hannesw> sorry oberhamsi misread what you wrote :)
[7:24] <hannesw> so we're on the same line. ok!
[7:24] <robi42> +1
[7:24] <oberhamsi> okay!
[7:24] <robi42> (ad `response-refactoring`: what about setting up some additional ringo code conventions? :) )
[7:24] <oberhamsi> we didn't think about timer() afair
[7:24] <hannesw> robi42 sorry if my comment was a bit rude :)
[7:25] <robi42> np
[7:25] <hannesw> i think we should just leave those finer issues to the author
[7:25] <hannesw> the basics such as indentation should be standardized
[7:25] <robi42> actually, those changes were intentionally "provocative" ;)
[7:25] <hannesw> hehe
[7:26] <robi42> imho, for example we should decide for " vs. '
[7:26] <hannesw> well i tend to leave those "finer" things to the author
[7:26] <hannesw> it's nice to have consistency within one file or function, but otherwise i don't care much
[7:27] <oberhamsi> i don't care about " or ' .. but named functions are something i grew to like
[7:27] <robi42> ok, so in case a file has mixed "/' let's cleanup to "? :)
[7:28] <hannesw> currently the require section mostly use ', and often the rest of the file uses "
[7:28] <hannesw> that's my fault i think
[7:29] <hannesw> I'm not too concerned about it. Whenever I add code, i look for what the nearest strings use
[7:29] <hannesw> if there's inconsistency within one function or require block, i'd fix it, but not otherwise
[7:29] <hannesw> but that's just me
[7:30] <robi42> ok, i see. so let's leave it to the author and try to stay consistent within the module at hand?
[7:30] <hannesw> but i think i would hate to be disallowed to use either ' or "
[7:30] <oberhamsi> okay
[7:30] <hannesw> +1
[7:32] <robi42> btw, if we opt to include response-refactoring in 0.6 we should adapt all current apps, of course
[7:32] <hannesw> yes
[7:32] <robi42> ringo-wiki et al.
[7:33] <hannesw> but using module.resolve(), not module.directory - i don't know if you read my monologue on that above, robi42
[7:34] <robi42> i did, +1 for module.resolve()
[7:34] <robi42> will module.resolve() be committed today?
[7:34] <hannesw> yes
[7:34] <robi42> great
[7:35] <hannesw> it's not really ready, but maybe one or two hours of work
[7:35] <hannesw> just have to sort out how to optimize initialization of module objects
[7:37] <hannesw> ok, next agenda item: anything else left to do for 0.6?
[7:37] <hannesw> i can't think of anything beyond what we already talked about
[7:38] <robi42> static docs generator's ready, right?
[7:38] <hannesw> but i want to deploy 0.6 on ringojs.org before release
[7:38] <hannesw> yes, it's built by the ant build script
[7:38] <hannesw> ant docs
[7:38] <robi42> great
[7:39] <hannesw> it builds both java and js docs
[7:39] <hannesw> there's a minimal overview page in docs/index.html
[7:39] <hannesw> that's a possible starting point for static ringojs.org site content also, i think
[7:40] <robi42> what about the `simplesite` thingy?
[7:40] <hannesw> yes, that could be used to publish static docs.
[7:41] <hannesw> so we could put markdown (.md) files into the ringojs docs folder
[7:41] <hannesw> and then use simplesite to deploy it on ringojs.org
[7:41] <robi42> cool
[7:41] <hannesw> not sure about formats. should we put both .html and .md files into docs?
[7:42] <hannesw> but that's for past 0.6, anyway
[7:45] <robi42> supporting both would be nice to have, yes
[7:47] <hannesw> should we beautify the docs/index.html page?
[7:47] <hannesw> or the module docs, for that matter? (which brings us to our last agenda item)
[7:48] <robi42> again, improved layout/design would be nice to have, but we can also add that later on
[7:48] <hannesw> ok, +1
[7:48] <oberhamsi> docs/index.html is just there to get you somewhere.. doesn't need prettiness imo
[7:48] <hannesw> good to have something left to do for next release :)
[7:49] <robi42> :)
[7:49] <hannesw> question is do we need it at all?
[7:49] <hannesw> (at this point)
[7:50] <oberhamsi> docs/index.html ... yes let's leave it, we don't have to deploy it on ringojs though
[7:50] <hannesw> ok
[7:52] <robi42> good, so there could be 0.6 release by the end of the week or beginning of upcoming one?
[7:54] <hannesw> even earlier i think
[7:54] <hannesw> let's see
[7:54] <robi42> :)
[7:54] <hannesw> ok, i think we're through with meeting agenda
[7:54] <hannesw> i already shifted to coding
[7:55] <hannesw> nice thing about module.resolve is you can leave away the "./" for relative path
[7:56] <robi42> yep, guess that could have caused some confusion/bugs by users in the end
[7:58] <hannesw> robi42 the skin resolving magic was really bad! I'm glad we can get rid of it
[12:11] <olegp> since when are local variables persisted across requests?
[12:24] <oberhamsi> olegp, local variables? modules are now shared by default so vars in module scope are persistent over requests
[12:25] <olegp> yeah, thats what I meant, cool
[12:25] <olegp> was just wondering when that change happened ..
[12:32] <oberhamsi> olegp, git says it happend on May 17 :) be01260f2449e1edc8
[12:32] <hannesw> olegp i think it was shortly before 0.5
[12:32] <hannesw> oh, oberhamsi beat me to it
[16:33] <oravecz> small bug in Session.isNew property definition (in ringo/webapp/request)
[16:33] <oravecz> return getSession().isNew();
[16:33] <oravecz> missing the 'return' keyword
[16:36] <oravecz> Is the Session tested and working?
[16:38] <oravecz> I'm having to rewrite part of it to support the use of PortletSession. When I execute:
[16:38] <oravecz> data = new JavaAdapter(Scriptable, {
[16:38] <oravecz> put: function(name, start, value) {
[16:38] <oravecz> getSession().setAttribute(name, Context.jsToJava(value, java.lang.Object));
[16:38] <oravecz> },
[16:38] <oravecz> get: function(name, start) {
[16:38] <oravecz> return Context.javaToJS(getSession().getAttribute(name), global);
[16:38] <oravecz> }
[16:38] <oravecz> });
[16:38] <oravecz> I end up with data as undefined and no error thrown
