Hopbot log for 2009-10-16 - Helma IRC channel: #helma on irc.freenode.net

2009-10-16:

[0:18] <jawe> hannesw_, danke f?r den hinweis auf idea!
[0:18] <hannesw_> hm, leider hat die community-edition beta kein javascript plugin ;(
[0:19] <hannesw_> javascript z?hlt wohl zu enterprise features
[0:19] <hannesw_> oder was...
[0:20] <jawe> jo fettes rotes kreuzerl bei allen javascript punkten in der feature comparison matrix
[0:21] * hannesw_ schl?gt h?nde vors gesicht
[0:22] <jawe> teaser edition w?r treffender als community edition :)
[0:23] <hannesw_> naja, vielleicht ein ansporn, helma support von grund auf zu machen...
[0:23] <hannesw_> aber schon mal sehr entt?uschend
[0:27] <emilis_info> hannesw_, thanks for the fix
[0:27] <emilis_info> :)
[0:27] <hannesw_> emilis_info: you're welcome!
[0:39] <jawe> hehe so gut wie alle tweets zu idea sagen "gut, ABER ..."
[1:35] <emilis_info> hm... so how do I use modules as classes -- to produce multiple objects with the same functionality? I ran into some strange situation where calling methods on cloned modules, modifies attributes in all clones...
[1:36] <emilis_info> cannot reproduce the bug in shell though
[1:36] <emilis_info> (Helma NG used)
[2:12] <hannesw_> emilis_info: using modules as classes doesn't sound right to me
[2:12] <hannesw_> why not use a js function/constructor?
[2:13] <emilis_info> well...
[2:13] <emilis_info> :)
[2:13] <emilis_info> I just wanted to try it out
[2:13] <emilis_info> anyway
[2:14] <emilis_info> I rewrote my code to use a function/constructor, and it is still behaving strangely
[2:16] <emilis_info> I have like a Document and DocumentList. In DocumentList I fill an Array with Documents. When I read data into a second Document, the first one in the Array is overwritten
[2:16] <emilis_info> I don't know if I describe the problem clearly
[2:17] <emilis_info> I think I found another bug
[2:17] <emilis_info> but it is very hard to isolate it
[2:18] <emilis_info> I am trying to reproduce the bug in the shell, but then it disappears
[2:18] <emilis_info> hmm
[2:18] <emilis_info> Maybe it is related to the way Helma handles modules...
[2:20] <emilis_info> Will try to create two test modules to reproduce it
[7:19] <hannesw_> emilis_info: If you want just paste your code here: http://helma.pastebin.com/
[7:20] <hannesw_> or send it to me via email
[7:20] <hannesw_> I'll look into it
[7:28] <emilis_info> hannesw_, sent to group
[7:28] <hannesw_> great, thanks
[7:28] <emilis_info> np :)
[7:29] <hannesw_> oh, ok, gmail thought it was spam
[7:31] <hannesw_> ok, i noted this behaviour, too.
[7:32] <hannesw_> not sure if it's a bug or just a result of JS operator precedence
[7:35] <hannesw_> yes, I think the problem is that "new" is kind of greedy and assocatates with the first function call (require(..)) instead of the second one
[7:42] <emilis_info> so... this should work?: new (require("module").constructor);
[7:43] <hannesw_> yes
[7:43] <emilis_info> ok, thanks :)
[7:43] <emilis_info> gtg now :)
[7:43] <hannesw_> new (require("module").constructor)(...)
[7:43] <emilis_info> ah
[7:43] <emilis_info> ok
[7:43] <hannesw_> It's confusing, i know
[7:47] <zumbrunn> var Foo = require("foo").constructor; new Foo(); is less confusing :-)
[8:17] <simono> also note that JS doesn't lend itself to classical OOP, though it gives the impression that it would
[10:34] <simono> how easy is it to change the module search path from within an NG script?
[10:34] <simono> i like the curr working dir in the search path, because it makes tinkering so easy
[10:40] <simono> if i have a ng script ~/binary.js that imports file (which in turn imports binary).. that would load my ~/binary.js, right? i shot myself in python like that
[12:04] <hannesw__> simono: currently you can tinker with the module path via helma/engine module
[12:04] <hannesw__> getRepositories(), addRepositories()
[12:05] <simono> ah nice
[12:07] <hannesw__> but it's getting easier
[12:07] <hannesw__> via require.paths, which should be an ordinary js array
[12:07] <hannesw__> http://github.com/hns/helma-ng/issues#issue/9
[12:08] <hannesw__> there are a few problems to solve... like automatic conversion between strings and repositories
[12:13] <simono> in the last paragraph you only give the option of adding the current-working-directory first in the searchpath
[12:13] <simono> but not the scripts-directory, which is the current default
[12:13] <simono> is that intentional?
[12:14] <simono> because of the /usr/local/bin problem?
[12:14] <hannesw__> last paragraph? of my mail?
[12:14] <simono> yes
[12:14] <hannesw__> well the scripts parent directory is the current behaviour, which obviously only works for a subset of applications
[12:15] <hannesw__> I think it isn't viable
[12:15] <simono> but the working directory would be more viable?
[12:15] <simono> one of both would be nice for tinkering
[12:16] <simono> "one of both" = one of working-dir or script-dir
[12:16] <hannesw__> yes, I think working dir is better.
[12:16] <hannesw__> you just cd to the app directory before running helma
[12:16] <simono> ok, sounds good
[12:17] <hannesw__> or we just don't set any module path at all...
[12:17] <simono> very strict, but less foot-shooting-potential
[12:19] <simono> i still remember the one time with python when i had an "image" directory in working directory and "import image" would fail strangely grr
[12:21] <hannesw__> well the thing is i usually sit in the helma-ng directory, and run various apps with "helma -i apps/foo/main.j"
[12:21] <hannesw__> so for me the script directory thing worked well
[12:21] <hannesw__> but i think typically people will not sit in the helma ng install directory
[12:21] <hannesw__> but in the directory of the app they're working on.
[12:22] <hannesw__> right?
[12:22] <simono> right!
[12:26] <simono> but developing modules, not apps, would be less adhoc... have to setup searchpath to do that
[12:31] <hannesw__> hm
[12:36] <simono> helma ~/dev/fooapp/main.js
[12:37] <simono> ~/dev/fooapp/awesomelib.js
[12:38] <simono> hm, so if i want to write import("awesomelib") in main.js, i would have start main.js from within fooapp/ .. hm
[12:39] <simono> i really think that either the working-dir or the script-dir should be in the searchpath, else scripts have a hard time importign modules they bring along
[12:40] <simono> and i think the script-dir makes more sense, because those extra modules are relative to the script
[12:43] <simono> realizing that relative imports kind of solve that, i'm still not sure :|
[13:51] <hannesw__> hm, me neither :/
[14:40] <simono> lacking a more intelligent task i gave helma-groups an icon, the shiny helma logo

 

 

In the channel now:

Logs by date: