Logs for the RingoJS IRC channel, as logged by ringostarr.

2010-07-20

[00:02] <tschaub> is all of ringojs/lib required to run a ringo app in a servlet container?

[00:02] <tschaub> (I'm curious in particular about the jetty jars)

[09:28] <gmosx> hey?

[10:07] <zumbrunn> regarding extending core prototypes...

[10:07] <zumbrunn> how about changing the core modules to be callable using a syntax like this:

[10:07] <zumbrunn> require('core/string').extend(String)

[10:09] <hannesw> zumbrunn: that would just make things worse imo

[10:10] <zumbrunn> it would?

[10:10] <hannesw> the problem is that code is extending core prototypes, not how it is doing it

[10:10] <zumbrunn> hmm, ok

[10:11] <hannesw> i also want to get rid of the core/* namespace

[10:11] <hannesw> and use ringo/util/* instead, or something similar

[10:11] <zumbrunn> yes, that's fine

[10:13] <hannesw> well the way i see it is the problem is extending core objects per se

[10:14] * zumbrunn doesn't think that is a problem

[10:14] <zumbrunn> but I agree one can see that differently

[10:14] <hannesw> what do you think is the problem?

[10:15] <zumbrunn> I really don't have a problem with the way we are currently doing it

[10:16] <zumbrunn> the require('core/string').extend(String) syntax would maybe be a better "best practice" for doing that

[10:17] <zumbrunn> (just because it makes clear what's happening)

[10:20] <zumbrunn> that way it is the calling module that extends its core prototypes in its own scope

[10:20] <zumbrunn> and the core/object etc modules do not do any dirty magic behind the scenes

[10:21] <hannesw> zumbrunn, to be clear:

[10:21] <hannesw> i don't have any problem with the current way either

[10:21] <hannesw> it's that people using ringo might have problems

[10:21] <zumbrunn> yep

[10:22] <hannesw> and the fact that we're using these extensions in our own ringo/* modules

[10:22] <hannesw> so you cannot not use them

[10:22] <hannesw> that's the problem we need to solve

[10:22] <zumbrunn> yes, I see

[10:22] <hannesw> and the only thing we can do is not touch core objects at all

[10:29] <zumbrunn> regarding a new implementation of skins...

[10:29] <zumbrunn> is it out of question to leverage e4x for that?

[10:31] <zumbrunn> (it may be considered to be limiting, but it would not be to limiting for me)

[10:32] <zumbrunn> (it may be considered to be *to* limiting, but it would not be to limiting for me)

[10:34] <gmosx> how about using

[10:35] <gmosx> var method = require("core/string").method ?

[10:35] <gmosx> ie, just require the functions you like (use functions, not methods)

[10:36] <gmosx> functions are better (faster dispatch, can check for null values, easier to optimize with closure compiler)

[10:38] <hannesw> gmosx yes, that's what I'm planning to do

[10:38] <gmosx> nice...

[10:38] <gmosx> and ringo/util is better...

[10:38] <gmosx> ...than core/*

[10:39] <gmosx> should I add String.unescapeHTML and Object.update to core/* to get rid of narwhal/html and narwhal/hash?

[10:40] <hannesw> yes, but core/* is a moving target now...

[10:40] <gmosx> I know... but let's add them so I can drop the narwhal dependency, and I can change this afterwards...

[10:40] <hannesw> ok

[10:41] <gmosx> unless you plan to work on core/* immediatelly

[10:41] <hannesw> no

[10:41] <gmosx> in this case, I can wait...

[10:41] <gmosx> perhaps I could introduce ringo/utils/string.js and add unescapeHTML there...

[10:41] <gmosx> and we can move the rest from core/string.js afterwards...

[10:42] <gmosx> what do you think?

[10:42] <hannesw> well that move will be quite pervasive

[10:42] <hannesw> lots of files touched

[10:42] <gmosx> we can have ringo/utils/string.js in paralel...

[10:42] <gmosx> we can use it for new code, deprecate core/string.js but still keep it until we update all the code...

[10:42] <hannesw> I'd prefer to have a single clear trasfer

[10:43] <hannesw> transfer

[10:43] <gmosx> OK, I think moving core/* should have a high priority though

[10:44] <hannesw> btw, gmosx your github fork has two commits that are obsolete, you might as well push --force a clean copy

[10:44] <gmosx> git push --force origin master ?

[10:44] <hannesw> that would make merging from your fork easier

[10:45] <gmosx> hannesw: it only says Everything up-to-date

[10:46] <hannesw> well you have two commits in there that are obsolete or already merged:

[10:46] <hannesw> http://github.com/ringo/ringojs/forkqueue

[10:47] <gmosx> dunno how to remove them :(

[10:47] <hannesw> maybe earl could help

[10:47] <gmosx> earl: ??

[10:49] <hannesw> well it's not a big problem

[10:49] <gmosx> OK...

[10:50] <gmosx> Another thing...

[10:50] <gmosx> I think you should release new versions of Ringo more often...

[10:50] <gmosx> for example once per month...

[10:51] <gmosx> it's ok to have less new features per version...

[10:51] <gmosx> have a look at NodeJs, they release a new version, every 2 commits ;-) :-D

[10:52] <gmosx> Another feature request...

[10:52] <hannesw> gmosx yes, possibly

[10:52] <gmosx> hannesw: Can you please, please merge the slf4 jars into ringo.jar (or even better remove the dependency altogether?)

[10:56] <hannesw> gmosx you could make your own build script to merge the jars

[10:57] <hannesw> we may use that in ringo for appengine-like deployments

[10:57] <gmosx> any example how this is done?

[10:57] <gmosx> I have limited experience with ant, etc :(

[10:58] <hannesw> i don't know, but there's good documentation available:

[10:58] <hannesw> http://ant.apache.org/manual/index.html

[10:58] <hannesw> http://ant.apache.org/manual/Tasks/jar.html

[10:58] <hannesw> we may add an ant task like jar-complete

[10:58] <hannesw> or whatever

[10:59] <hannesw> regarding removing the dependency:

[10:59] <hannesw> then we'd have to settle for one logging system, like log4j or java.util.logging

[11:00] <hannesw> and everything other than the latter wouldn't work on appengine

[11:00] <gmosx> i think appengine supports log4j

[11:01] <gmosx> no Appengine supports BOTH log4j and java.util.logging

[11:01] <gmosx> slf4j is not really needed...

[11:01] <gmosx> and it makes this examples more complex for new users...

[11:02] <gmosx> (I got a question regarding the many jars in the aejs group)

[11:02] <hannesw> log4j does not really work

[11:02] <gmosx> we should make ringo and aejs less intimidating for new users?

[11:02] <hannesw> if you log to stdout or stderr it will end up in the log, but that's not really logging

[11:04] <hannesw> ok, so let's make a jar-complete ant task

[11:07] <gmosx> http://code.google.com/appengine/docs/java/runtime.html#Logging

[11:07] <gmosx> jar-complete RULEZ ;-)

[11:07] <gmosx> thanks

[11:07] <gmosx> you are right, seems to support only java.util.logging...

[11:07] <gmosx> I think RingoJS should only support this by default to be lightweight...

[11:08] <gmosx> if the developer needs log4j he can add this...

[11:08] <gmosx> what do you think? ;-)

[11:08] <hannesw> yes, that's an option

[11:09] <gmosx> I vote for simplicity ;-)

[12:10] <gmosx> hannesw: btw, check this out: http://news.ycombinator.com/item?id=1531583

[12:10] <gmosx> it rocks ;-)

[17:32] <emilis_info> I need to check if new files have been added to a directory. What would you propose?

[17:33] <emilis_info> I would compare arrays from fs.list() but there is no Array.diff...

[17:42] <mcepl> write one? ;)

[17:42] <emilis_info> or not to write one ;-)

[17:43] <daian> that is the question