*** cilkay has quit IRC
*** sjc has joined #gnuenterprise
*** holycow has quit IRC
*** kilo has joined #gnuenterprise
<kilo> good morning
<dimas> hello kilo
<kilo> hi dimas
*** btami has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
<dimas> hi reinhard
<reinhard> good morning
<dimas> if i have xmlrpc set for both side which driver really used?
<dimas> as /rpc/drivers/xmlrpc only has code for py_xmlrpc and pw_xmlrpc
<reinhard> it uses the first one that it finds and that it can load
<dimas> does xmlrpc real driver or just common name for particular driver to be found?
<reinhard> xmlrpc is just a common name for both
<reinhard> it's actually a feature of the plugin loader
<reinhard> it's like if you say "provider = postgres" in your connections.conf, the loader tries all of psycopg, pypgsql, pygresql and popy and loads the first it can initialize
*** sjc has quit IRC
<dimas> ok
<dimas> reinhard: i had everythings working with rpctype=xmlrpc until i thought to try filters again
<dimas>    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/common/datasources/drivers/appserver/appserver/Connection.py", line 78, in getLoginFields
<dimas>     self._filters = self._sm.getFilters (self.parameters.get ('_language', 'C'))
<dimas>    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/common/rpc/drivers/Base.py", line 241, in __call__
<dimas>     return self._adapter._runMethod (self._methodname, *args, **params)
<dimas>    File "/home/ds/svn/gnue/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/pw_xmlrpc/ClientAdapter.py", line 98, in _runMethod
<dimas>     result = to_call (*__args, **params)
<dimas>    File "/usr/lib/python2.3/xmlrpclib.pyc", line 1029, in __call__
<dimas>    File "/usr/lib/python2.3/xmlrpclib.pyc", line 1316, in __request
<dimas>    File "/usr/lib/python2.3/xmlrpclib.pyc", line 1070, in request
<dimas>  ProtocolError: <ProtocolError for localhost:8765/: 500 Internal error>
<dimas> more about that
<dimas> if filters are defined but not no real data (like base_company) exist - forms give login screen with additional fields
<dimas> when i inserted base_company - it fails even before that
<reinhard> appserver and forms on same machine?
<dimas> yes
<dimas> <dimas>     self._filters = self._sm.getFilters (self.parameters.get ('_language', 'C'))
<dimas> how can i check that lagnuages are properly initialized? C and ru
<dimas> languages
<dimas> as somewhere in gld "ru" is used
<reinhard> can you please try if something changes if you run both appserver and forms in the C locale?
<dimas> ok
<reinhard> I think we are facing a unicode problem here
<dimas> reinhard: is that ok to switch to C locale - LANG=C gacvs ....   ?
<reinhard> please check what variables you have set
<reinhard> LANG, LANGUAGE and LC_ALL can be relevant
*** dcmwai has quit IRC
<dimas> the same error
<dimas> and value for filter in base_company all in ascii
<dimas> it gives that on server side
<dimas> DB003: 0:00:27.201 [Connection:248] DBSIG2 Statement: SELECT t0.base_name,t0.base_code,t0.gnue_id FROM base_company t0
<dimas> DB003: 0:00:27.203 [Connection:249] DBSIG2 Parameters: None
<dimas> 
<dimas> am i missed something with setting filters again?
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<johannesV> reinhard, what's the differenence between @param, @cvar and @ivar ?
<reinhard> brb phone
<reinhard> back
<reinhard> hi johannesV
<reinhard> cvar is for class variables
<reinhard> ivar is for instance variables
<reinhard> @param is not parsed correctly at all if used in a class docstring
<johannesV> strange ...
<johannesV> so what to use for parameters of a function from a class ?
<reinhard> dimas: my suspection is that there is a server side exception and xmlrpc fails to pass the exception details because they contain unicode
<reinhard> but that's a guess, nothing more
<reinhard> johannesV: you can use @param in a function or method definition, but not in the docstring of the class itself
<reinhard> class foo:
<reinhard>   """
<reinhard>   bar
<reinhard>   """
<reinhard>   def method (self):
<reinhard>    """ baz """
<reinhard>     pass
<reinhard> you can use @param in baz, but not in bar
<johannesV> ah, ok, now i see
<johannesV> phu ... :)
<reinhard> and you can use ivar and cvar in bar, but not in baz
<johannesV> ok, rigth
<ajmitch> hi
<johannesV> s/rigth/right
<johannesV> i was just wonder while i was reading the commit mails
<reinhard> I found out yesterday that it improves the usability of the docstrings quite a lot if you look at the generated output from time to time :-)
<reinhard> hi ajmitch
<reinhard> is it possible that you forgot to bump up appserver's dependency to common to the newest common release?
<johannesV> so you'd say we should add @ivar/cvar to every class ?
<reinhard> http://www.gnuenterprise.org/tools/common/docs/api/public/gnue.common.apps.GBaseApp.GBaseApp-class.php is a good example maybe
<reinhard> all class variables are listed for any class *anyway*
<reinhard> all you do with @cvar is add an explanation to it
<reinhard> also, adding @ivar and @cvar to the docstrings might help defining the "public interface" of a class
<reinhard> I would *only* document the public variables of course
<reinhard> plus for abstract base classes the @cvar's that should be overwritten by descendants
<johannesV> i agree; it makes sense
<ajmitch> reinhard: I thought i had bumped the dep
<dimas> reinhard: i've removed all references to ru from filters - same error, deleted filter value - it opened the login dialog
<ajmitch> checking now
<ajmitch> Package: gnue-appserver
<ajmitch> Architecture: all
<ajmitch> Depends: ${python:Depends}, gnue-common (>= 0.5.14)
<dimas> filter value was : tandem=#  SELECT t0.base_name,t0.base_code,t0.gnue_id FROM base_company t0;
<dimas>  base_name | base_code |             gnue_id
<dimas> -----------+-----------+----------------------------------
<dimas>  tandem    | t         | 11d99139ce7ed9b28ab40058bf000436
<dimas> (
<ajmitch> the previous version didn't get changed for some reason
<johannesV> dimas, do you have a valid gld defined for that filter-class base_company ?
<reinhard> johannesV: also I tried to be a little consistent in the docstrings, e.g. every function has a first short paragraph that says what the function does in imperative form -- this first paragraph is displayed in the overview page
<reinhard> but this is getting close to Monk-like behaviour ;-)
<reinhard> ajmitch: yes, you're right, must have looked in the testing version, sorry
<dimas> <module name="base" language="C">
<dimas>   <class name="company" label="Company">
<dimas>     <property name="code"     pos="100" label="Code"          search="100" />
<dimas>     <property name="name"     pos="200" label="Name"          search="200" />
<dimas>   </class>
<dimas> 
<johannesV> btw, testing the new repository i've found another memory leak in using generated forms ...
<reinhard> dimas: you have also run the appserver with LANG=C ?
<dimas> yes
<johannesV> i've to run again ... bbl
*** ajmitch has quit IRC
<reinhard> dimas: you using svn, right?
*** ajmitch has joined #gnuenterprise
<reinhard> with --debug-level=3 on forms side you can see all rpc calls
<reinhard> and with --debug-level=4 on appserver side you can see how they arrive at appserver
<reinhard> although there will be much more output on appserver
<reinhard> because appserver uses itself internally
<ajmitch> reinhard: 0.4.1 has got a dependency on the latest common (if you didn't see it before I reonnected)
<reinhard> <reinhard> ajmitch: yes, you're right, must have looked in the testing version,
<reinhard> sorry
<ajmitch> ok :)
<ajmitch> sorry, was a bug in the testing version I suspect
<dimas> reinhard: yep for svn, i see debug messages, will try to insert filter value back
*** ciccio has joined #gnuenterprise
<ciccio> reinhard: any chance to enter in private contact with you?
<reinhard> what do you mean with "private contact"?
<reinhard> you mean meeting me in real life?
<ciccio> não. this might be complicated by some 12.000km
<ciccio> no
<ciccio> I think you are in Austria, I am in Brasil
<kilo> st helens island is a great place...
<reinhard> ciccio: so what do you mean?
<ciccio> email. IM what ever, so the conversation isn't public anymore
<dimas> reinhard: last debug message on server side:
<dimas> DB004: 0:01:56.824 [geasSessionManager:403] Leaving function gnue.appserver.geasSessionManager.geasSessionManager.getFilters ('0x4071e3cc') == [((u'base_company', u'Company'), [(u'Code', True, u'base_code'), (u'Name', True, u'base_name')], None, {None: [{u'base_code': u't', 'gnue_id': u'11d9915191c3a9169d280058bf000436', u'base_name': u'tandem'}]})]
<dimas> 
<reinhard> can you try to find out which xmlrpc driver you actually use?
<reinhard> off to lunch, bbl
<dimas> as i have no py_xmlrpc installed it could only be pw_xmlrpc
*** mnemoc_ has quit IRC
*** tiredbones has joined #gnuenterprise
*** mnemoc has joined #gnuenterprise
*** btami has quit IRC
*** kilo has quit IRC
*** kilo has joined #gnuenterprise
<reinhard> back
<johannesV> reinhard, i've just fixed the memory leak for generated forms ... (will add it to the repository-commit then)
<reinhard> johannesV: ok
*** mnemoc has quit IRC
<reinhard> dimas: for me, getFilters returns more or less exactly the same and it works
<reinhard> you sure you have no local modifications of the code (e.g. from earlier tests in rpc) and are up to date with latest svn in appserver and common?
<dimas> Dispatching:  Session.getFilters ('C',) <- is that looks ok?
<reinhard> yes
<dimas> reinhard: how to get low level debug output on server side? like if i put some prints in xmlprc.py?
<dimas> reinhard: downloaded fresh copy for appserver and common/rpc - same thing
<johannesV> another (big) memory leak found ... created on sighup to appserver ....
<reinhard> dimas: in rpc/drivers/xmlrpc/ServerAdapter.py, line 312, you could add a print repr (result)
<reinhard> maybe also in line 361 of the same file
*** ncjp has quit IRC
*** ncjp has joined #gnuenterprise
<dimas> it outputs from line 312
<dimas>  [((u'base_company', u'Company'), [(u'Code', True, u'base_code'), (u'Name', True, u'base_name')], '', {'': [{u'base_code': u't', 'gnue_id': u'11d9915191c3a9169d280058bf000436', u'base_name': u'tandem'}]})]
*** lekma has joined #gnuenterprise
<lekma> hi
<lekma> strikes here in paris
<lekma> everywhere
*** mnemoc has joined #gnuenterprise
<dimas> lekma: against software patent?
<lekma> nope
<lekma> against the european constitution
<lekma> for more money in scientific research
<lekma> to keep the school system fair for every students
<lekma> the patent pb doesn't seem to receive a lot of media coverage here
<reinhard> dimas: does line 361 issue the same?
<lekma> (i mean mainstream media)
<dimas> reinhard: no
<reinhard> dimas: ah! that's interesting
<dimas> should go, bbl
*** kilo has quit IRC
*** jamest_ has joined #gnuenterprise
*** jamest_ has quit IRC
*** jamest_ has joined #gnuenterprise
<johannesV> bbl
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
<lekma> reinhard: is there a way to know the language the session has been open with??
<lekma> is it in session.parameters??
*** johannesV_ has joined #gnuenterprise
<lekma> or can i use session.locale??
<reinhard> wait a minute
<reinhard> seems like you have to check for session.parameters ['_language']
<lekma> thx reinhard
<lekma> btw would it be the also the preferred way to check for username and password?
<reinhard> hmm - not sure if you have to check for 'language' or '_language'..
<lekma> in geasSession line 118: self.locale  = params.get ('language')
<lekma> i'll test with both
<reinhard> lekma: I think this is a typo and should be _language
<lekma> oh
<lekma> :)
*** johannesV has quit IRC
<lekma> print session.parameters says {u'password': None, u'user': None, u'language': u'fr'}
<reinhard> doh
<reinhard> hmmm
<reinhard> double doh
<lekma> :)
<reinhard> *you* pass that as parameter to open()
<reinhard> in the rpc interface
<lekma> yep
<reinhard> so basically you can pass what you want and appserver will give it via parameters
<lekma> i shouldn't?
*** dcmwai has joined #gnuenterprise
<reinhard> it seems like parts of appserver uses "language" and parts use "_language"
<reinhard> and gnue-forms seems to pass "language"
<lekma> that's why i did the same
<reinhard> err
<reinhard> gnue-forms passes "_language"
<reinhard> so when you use gnue-forms, you would see exceptions in the wrong language (how the server was started) but see messages in the correct language
<reinhard> (messages from gld files)
<reinhard> and with your frontend, it would be exactly the other way around
<reinhard> but I will test
<lekma> i used to start generated gnue-forms with appserver://form/some_class?language=fr
<lekma> and i saw that it took it as the form lang
<reinhard> yep ok
<lekma> so i thougth the correct way was to pass the same dict
<reinhard> but it should be sufficient to just start gnue-forms with LANG set in the environment
<reinhard> and gnue-forms should pass that to the server
<reinhard> IIRC
<lekma> i'm ashamed to say that i don't know how to set LANG in win32
<lekma> :)
<lekma> so in my login form there is a dropdown to choose session lang
<reinhard> ah ok
<reinhard> I always forget that there is something outside the posix world :)
<reinhard> lekma: I would not count on the password being available in the parameters dict in the long run
<reinhard> as it's a *huge* security risk..
<lekma> i agree
<lekma> i thougth about hashing it in md5 in the meantime
<lekma> but got caught up by more concrete thing to do first
<mnemoc> join #openldap
<mnemoc> err
<mnemoc> sorry
<mnemoc> doesn't exist :(
<lekma> sigh
<lekma> i wish this project would finish and give me time to do more concrete things for gnue
*** tiredbones has quit IRC
<dimas> back
<johannesV_> great, all 6240 dead objects found :)
*** chillywilly has quit IRC
*** chillywilly has joined #gnuenterprise
*** sjc has joined #gnuenterprise
<mnemoc> :D
*** SachaS has joined #gnuenterprise
*** cilkay has joined #gnuenterprise
*** tiredbones has joined #gnuenterprise
*** dimas has quit IRC
*** dcmwai has quit IRC
*** lekma has quit IRC
*** johannesV_ has quit IRC
*** SachaS_ has joined #gnuenterprise
*** SachaS has quit IRC
*** SachaS_ has quit IRC
*** ciccio has quit IRC
*** kilo has joined #gnuenterprise
<kilo> reinhard is commit masta...
<reinhard> jcater: thanks for that fix
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
<jcater> ah, nothing like designer locking X up
<reinhard> jcater: thanks for that fix
<jcater> just like old times
<jcater> np
<jamest_> reinhard been running common based stuff all day w/ no issues
<jamest_> lol google for postgresql popy
*** jamest_ has quit IRC
<jcater> hmm
<jcater> I need some postgres help
<jcater> in oracle I could do the equiv of
<jcater> select ... from mytable where date1 >= now()::date - 30;
<jcater> but the postgres equiv gives
<jcater> ERROR:  operator does not exist: date - numeric
<jcater> what do I need to typecast the 30 with to get it as "days"?
<mnemoc> .oO( i though python do that magicly )o
<jcater> not in python
<jcater> postgres
<mnemoc> :)
<jcater> ah
<reinhard> jcater: wow, that's way beyond the stuff I did with postgres
<jcater> select now()::date - '30 days'::interval;
<jcater> seems to do the trick
<reinhard> in fact, that's way beyond the stuff I did with SQL at all :)
<mnemoc> *g*
* jcater is having a hard time adjusting from oracle to postgresql
<reinhard> just did a quite big commit
<reinhard> jcater: if you could please check oracle if you have time (made some updates to the drivers)
<reinhard> I have checked postgres and johannes can check the other maintained drivers
<reinhard> FWIW, starting from this commit the "host=" parameter in connections.conf is optional for postgres
<reinhard> and not giving that parameter will do a local (non-tcp) connection to the db
<reinhard> might be interesting WRT performance
<jcater> cool
<jcater> but fwiw
<jcater> [gnue]
<jcater> comment = GNUe Test
<jcater> provider = pypgsql
<jcater> host = /var/run/postgresql
<jcater> dbname = gnue
<jcater> has always done that
<jcater> (and it does give performance boost)
<jcater> but it is nice to have it default to that, as I always forget the line to use
<reinhard> did this work for all postgres drivers?
<jcater> worked for psycopg and pypgsql
<jcater> not sure about all though
<jcater> I think it was the postgresql client library that supported it
<jcater> not the python db library
<reinhard> ah ok
<jcater> fwiw
<jcater> I found this out by accident when setting up my zope site
<jcater> saw that I could do it there
<jcater> and tried it with gnue
<jcater> (and it worked)
*** kilo has quit IRC
*** jcater has quit IRC
<reinhard> night all
*** reinhard has quit IRC
*** sjc has quit IRC
*** tiredbones has quit IRC
*** jcater has joined #gnuenterprise
*** jamest has quit IRC
*** jcater has quit IRC
*** dcmwai has joined #gnuenterprise
*** dimas has joined #gnuenterprise
*** dimas has quit IRC