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

2010-06-24

[01:02] <Cainus> hey all... the latest from git has 3 failing unit tests... should I be worried?

[01:16] <earl> Cainus: no need to worry. those are known problems resulting from a recent switch to commonjs-conformant unit testing

[01:17] <Cainus> cool thanks

[08:46] <gmosx> good morning!

[08:52] <hannesw> good morning

[08:56] <gmosx> hannesw: maybe it would be a good idea to extract stuff like skins, or the web framework in a separate package and have a leaner ringo core

[08:56] <gmosx> (but please leave request/response in the core along with jsgi)

[09:02] <hannesw> gmosx yes, that's been a consideration for a long time

[09:02] <gmosx> ok

[09:03] <hannesw> skin thing is something I'm not really happy with

[09:03] <hannesw> I'm going to rewrite it anyway, so maybe also decouple it in the process

[09:04] <gmosx> yeah...

[09:04] <gmosx> perhaps you should also remove storage from the core...

[09:05] <gmosx> and even the middleware stuff (maybe put them in a ringo-webapp package along with the other web related stuff)

[09:05] <gmosx> (but let me repeat, keep request, response in the core along with jsgi)

[09:06] <hannesw> why not have middleware in core? it's just jsgi, thus framework agnostic

[09:27] <gmosx> OK, if you think it belongs to the core :)

[09:28] <gmosx> perhaps leave webapp in the core too...

[09:29] <gmosx> btw, perhaps you should move ringo/jsgi.js to /jsgi.js (top level)

[09:33] <hannesw> jsgi is not a user facing module - you never need it

[09:34] <hannesw> there's this really interesting blog post by isaac schlueter i read yesterday:

[09:34] <gmosx> but it's a commonjs ratified module, should belong in the top level... think about it...

[09:34] <hannesw> http://blog.izs.me/post/729604080/nodejs-and-empowering-n00bz

[09:35] <hannesw> i think we can learn a _lot_ from this

[09:35] <gmosx> let me check this out...

[09:35] <hannesw> ringo really lacks simple examples - even experienced users asking for the simples possible hello world app

[09:36] <hannesw> node.js has this stuff right on the front page

[09:36] <hannesw> so i think we might learn from that, and instead of listing features, put a simple hello world app right on there as well

[09:36] <gmosx> yeah...

[09:36] <gmosx> ringo is relatively easy to get starte with too...

[09:37] <gmosx> it's easier for example than narwhal...

[09:37] <gmosx> but there is always room for improvement...

[09:37] <gmosx> indeed, you should add a couple of simple examples on the homepage

[09:38] <gmosx> oh, and more videos...

[09:38] <gmosx> your videos made me switch to RingoJS btw...

[09:38] <gmosx> great videos...

[09:38] <hannesw> thanks :)

[09:38] <hannesw> still learning

[09:38] <gmosx> (perhaps you should update that GAE video with an appenginejs example, hint, hint ;-))

[09:39] <hannesw> btw, your blog post brough as ~1000 new visitors yesterday

[09:39] <hannesw> and today it's alredy > 3 times the usual number of visitors

[09:39] <hannesw> so that was just great

[09:39] <gmosx> nice, we don't need visitors, we need users though ;-)

[09:40] <hannesw> i think lot's of new people found it quite interesting

[09:40] <hannesw> based on tweets and github watchers

[09:40] <hannesw> so this exposure is exactly what's needed

[09:40] <gmosx> of course: it's a great project!

[09:40] <gmosx> you guys have done a great job!

[09:41] <hannesw> :)

[09:41] <hannesw> but a terrible one at creating a buzz

[09:41] <gmosx> perhaps you should organize an irc meeting about 'marketing'

[09:41] <gmosx> some coordinated efforts could do wonders...

[09:43] <hannesw> why coordinate? if a few people start talking/blogging, isn't that what's missing?

[09:43] <gmosx> you should coordinate the tlaking/blogging part to send out a clear message...

[09:44] <gmosx> focused on the merits of Ringo...

[09:44] <hannesw> right now figuring out which way to go with my new blog

[09:44] <hannesw> think i might use github pages and jekyll

[09:44] <gmosx> sounds good...

[09:44] <gmosx> get something up and running :)

[09:45] <hannesw> yeah

[09:45] <gmosx> add disqus for comments...

[09:45] <hannesw> right

[12:52] <robi42> hannesw, github/jekyll/disqus blogging would do just fine. the earlier there's something out there now the better, i think. :)

[12:54] <hannesw> yes, will try to get it up today/tomorrow

[12:54] <robi42> great

[15:39] <tschaub> this is not ringo specific, but I'm wondering if someone can help me with a rhino question

[15:40] <tschaub> I need to create an instance using a Java class with two candidate constructors

[15:40] <tschaub> com.example.Foo(com.example.Bar[]) and com.example.Foo(com.example.Baz[])

[15:41] <tschaub> I've got a JavaScript array of Bar objects

[15:42] <tschaub> and I get "The choice of Java constructor Foo matching JavaScript argument types (object) is ambiguous"

[15:49] <earl> tschaub: you'll need to explicitly specify which ctor to call

[15:49] <tschaub> earl: can I do that from js?

[15:49] <earl> sthg like `com.example.Foo["(com.example.Bar[])"](arrayOfBars)`

[15:51] <earl> does that work?

[15:52] <tschaub> doesn't look like it - it's looking specifically for a property on the Foo function named "(com.example...") in that case

[15:53] <tschaub> only properties listed are name, arguments, arity, length, prototype

[15:53] <tschaub> seems like I should be able to create a typed array

[15:53] <earl> let me look up the reference

[15:54] <earl> maybe it doesn't work for non-primitive types

[15:54] <earl> http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html#ExplicitMethod

[15:57] <tschaub> interesting, thanks earl

[15:57] <tschaub> looks like it should work

[15:57] <earl> well, not sure if it does for non-primitives

[15:57] <tschaub> it's likely complicated on my side because I'm using a factory function as well

[15:59] <earl> hannesw is probably the right person to ping re this, i think he knows those intricacies fairly well

[16:03] <tschaub> earl: it looks like java.lang.reflect.Array.newInstance(com.example.Foo, 10) may work

[16:04] <tschaub> cool, it does work

[16:04] <earl> great :)

[16:04] <tschaub> thanks for the pointers - those are good docs to have handy

[16:06] * tschaub -> airplane

[16:59] <oravecz> adding to the conversation between hannesw and gmosx yesterday, I have a couple suggestions

[16:59] <gmosx> oravecz: ?

[17:00] <oravecz> +1 on separating skins into a package, should be able to use skins, mustache, ejs, etc as easy as adding a package

[17:00] <gmosx> yes

[17:01] <oravecz> The config.js assumes a single web application per deployment. Perhaps considering an approach similar to web.xml is more flexible.

[17:02] <gmosx> hmm, dunno about that...

[17:03] <gmosx> I don't use most of the features of config.js or the webapp framework anw...

[17:03] <gmosx> so I am not the right person to comment on this

[17:04] <oravecz> just throwing it out there if there is going to be some consideration for developing enterprise apps

[17:04] <oravecz> it is fairly common to bundle multiple servlets in a web app

[17:04] <oravecz> and each servlet can have a different stack of filters applied against it

[17:05] <gmosx> yeah... In my projects I go a step further, every single uri is handled by a different (JSGI) app, and a dispatcher middleware selects the appropriate app

[17:06] <oravecz> that's an example of one extreme :D

[17:06] <gmosx> :-)

[17:07] <gmosx> but works well in practice... very simple to understand and debug the app...

[17:07] <oravecz> we are probably on the other extreme, large enterprise project using maven and other components of Java ecosystem (Spring, spring security, portlets)

[17:07] <oravecz> but building everything on ringojs

[17:07] <gmosx> sounds like ...fun :-D

[17:08] <robi42> btw, ringo/webapp's config.js allows for multi-app setups; example: http://github.com/ringo/ringojs.org :)

[17:08] <kwhinnery> well, that's the big allure of using a JVM-based framework - you can put it over the top of existing Java codebases and not have to work with a crappy Java web framework

[17:08] <gmosx> kwhinnery: right!

[17:09] <oravecz> robi42,are you referencing the demo app?

[17:09] <robi42> nope, that's the app running ringojs.org

[17:10] <oravecz> but where does it show how I can apply different middleware stacks based on app?

[17:11] <gmosx> you could use a simple middleware like this:

[17:11] <robi42> well, basically you've got a general config.js there and then resp. config.js' for each sub app

[17:11] <gmosx> http://gist.github.com/451564

[17:12] <gmosx> can you have multiple configs?

[17:12] <robi42> each app has its own config

[17:13] <robi42> iirc :)

[17:26] <hannesw> if you map a pattern to another config, that config takes on from there

[17:27] <hannesw> so yes, you can nest configs (and webapps)

[17:37] <oravecz> hannesw: any progress on how I can resolve js files to ringo.jar, while also locating js files in my app's directory structure?

[17:38] <oravecz> i should add, when deployed as a servlet

[17:44] <oravecz> it seems that creating a path to ringo.jar is problematic because it depends it isn't relative to any particular path. On my mac dev env, it seems to be relative to the directory I am in when I launch maven.

[17:47] <oravecz> The Apache VFS stuff is pretty cool. If ringo would use it, we could specify resource paths using loacal/remote filesystems, jar/zip files, and even the classpath.

[17:47] <oravecz> http://commons.apache.org/vfs/filesystems.html#Zip, Jar and Tar

[17:50] <oravecz> it also looks like commons vfs supports a cache strategy to allow for easy config of production/dev behavior involving caching