*** Ahewes has quit IRC *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** holycow has quit IRC *** holycow has joined #gnuenterprise *** dcmwai has joined #gnuenterprise *** reinhard has joined #gnuenterprise *** btami has joined #gnuenterprise good morning *** holycow has quit IRC good morning all *** johannesV has joined #gnuenterprise good morning *** kilo has joined #gnuenterprise good morning anyone using python < 2.3 with gnue here ? dimas had a strange error in xmlrpc yesterday ... nope ok, maybe i can setup a box with python2.1 then ... reinhard, on a woody box ? *** SachaS has quit IRC btami: no, reinhard uses sarge i don't know which os dimas is using but AFAICT sarge has full support for 2.1, 2.2 and 2.3 *** dcmwai has quit IRC johannesV: could you please take a look at gnue-invoice? i can show some strange things happening there *** dcmwai has joined #gnuenterprise in INV_grid.gfd, line 135, that code works perfect. i increase a counter, commit it and print a report, and the report shows the increased number kilo, i'm a bit short with time atm, but maybe we can do it a bit later today ... but in INV_Head, line 256, does not do the same... ok, kick me awake when you have time then *** dcmwai_ has joined #gnuenterprise ok, i will do so thx *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise good morning *** sjc has joined #gnuenterprise *** tunde has joined #gnuenterprise hi tunde .) hi btami, changing personality back to kilo... *** tunde has quit IRC *** dimas has quit IRC *** dimas has joined #gnuenterprise *** dcmwai has quit IRC *** sjc has quit IRC which packet sarge's py_xmlrpc in? is there py_xmlrpc available for python2.3 in sarge? ok, it was discussed before dimas, xmlrpc is part of python2.3, it's not a package on it's own but py_xmlrpc does not available, right? no, because xmlrpc is built into python2.3; there's no package py_xmlrpc anymore (as far as i can tell) but i think reinhard knows more about this, since he's the xml-rpc guy ... i have a problem with pw_xmlrpc when .gld has localized labels what kind of encoding do you define within the gld ? i used koi8-r ok, and the first line looked like: yep so it should work well then ... have you tried such an encoding with '.gfd' yet ? it works fine there ah, so sax works fine with it can koi8-r be expressed with utf8 ? johannesV: if i use authentication, on generated forms username is written over Last modified and Created dates oh, haven't tried authentication for a while ... :) but i can have a look at this in the later afternoon can koi8-r be expressed with utf8 ? seems so do you encounter the same problem with the gld if you use utf8-encoding then ? all forms and gld worked fine with py_xmlrpc, python 2.2.2 and old appserver way with labels on another machine we're using localized gld's here without problems, but we're using python2.3 then i can try to check this using python2.1 on another site, but this might take some time to get it up i have these problem on sarge machine with python2.3 problems ah, i thought it does *not* work on python2.2 ... little success story: installed win32 version of common, forms and reports on an XP, set up connection to a Linux box running AppServer, and run GNUe-Invoice at first try. I am happy. will try to recode gld so this makes things a bit easier to test is "koi8-r" your locales encoding ? like "latin-1" is mine ? yep hmm, using a gld encoded in 'latin-1' works fine for me dimas, if you do something like: gfcvs appserver://appserver/form/my_class?debug-file=foo.gfd you can afterwards look at the gfd generated by appserver this file should be encoded in 'utf-8' yes, i use this is this file properly encoded ? seems like it throws an exception before dumping to file dimas, the bug with the username written over the date-field should be fixed *** ra3vat has joined #gnuenterprise dimas, so you're using wx-driver ? yes hm, it's working with wx for me too we should have a better exception-handler for wx (like we have it for gtk2, where one can copy and past tracebacks) s/past/paste/ with python 2.3, pw_xmlrpc should be used (which is built into python lib) not sure if py_xmlrpc is available at all for python > 2.1 anyone here (except dimas/ra3vat) having a postgresql in locale-encoding (not unicode) running with appserver ? I'm pretty sure mine runs with utf-8 but how could I tell? reinhard, you've created the db's using --createdb, don't you ? in this case they'd been created with encoding=unicode ah ok btw. you can check it in psql with "SHOW server_encoding ;" dimas is running his backend (pgsql) with koi8-r encoding and he's not able to load gnue.gsd without the dbsig2-driver complaining about invalid encoding/commands example: ra3vat DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/datasources/drivers/DBSIG2/Connection.py", line 297, in makecursor ra3vat DB000: cursor.execute (s) ra3vat DB000: ProgrammingError: ERROR: ignoring unconvertible UTF-8 character 0xd3cf ra3vat DB000: ra3vat DB000: CREATE TABLE gnue_module (gnue_comment varchar (70), gnue_id varchar (32) NOT NULL, gnue_name varchar (35) NOT NULL, CONSTRAINT pk_gnue_module PRIMARY KEY (gnue_id)); well, this is really strange though ... btw. where is "koi8-r" usually used (geographically) ? hmmm unicode character d3cf is HANGUL SYLLABLE PYEOH johannesV: should i set encoding in connections.conf for utf-8 db encoding? * johannesV phone dimas: at least you can try :) hav you set encoding in connections.conf to koi8-r now? *** jamest has joined #gnuenterprise reinhard: i use utf-8 now on another machine with python2.2.2 ok, back again *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise reinhard, setting encoding in connections.conf helped to init UNICODE db and load gnue.gsd and to what value did you set the encoding? utf-8 IIRC the defalt for encoding is "iso-8859-1" which is not sane at all in your case ok excellent *** kilo has quit IRC *** johannesV_ has joined #gnuenterprise johannesV: is that a proper setting for gnue.conf rpctype = xmlrpc.pw_xmlrpc ? yes back again ... phu, i'm very busy at the phone today .. with pw_xmlrpc set everywhere i'm getting on python2.2.2 machine: dimas, yes i think that's a valid setting DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/Base.py", line 232, in __call__ DB000: return self._adapter._runMethod (self._methodname, *args, **params) DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/py_xmlrpc/ClientAdapter.py", line 98, in _runMethod DB000: result = self._client.execute (method, __args, self._timeout) DB000: File "/usr/lib/python2.2/site-packages/xmlrpc.py", line 217, in execute DB000: return self._o.execute(method, params, timeout, name, passw) DB000: xmlrpc.fault: (1, 'system\xc2\x91TypeError\xc2\x91isinstance() arg 2 must be a class, type, or tuple of classes and types\xc2\x91Traceback (most recent call last):\n File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/pw_xmlrpc/typeconv.py", line 119, in rpc_to_python\n elif isinstance (value, xmlrpclib.boolean):\n TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types\n') why is there py_xmlrpc/ClientAdapter in use ??? dimas: did you restart the server after setting pw_xmlrpc? 10 times already ok the server seems to still use py_xmlrpc to set what the server should use, you have to set rpctype in [appserver] section in gnue.conf connections.conf is only client setting sorry for not telling this earlier :-( didn't think of it [ds@exodus scripts]$ cat ~/gnue/etc/gnue.conf |grep rpctype #rpctype = xmlrpc.py_xmlrpc rpctype = xmlrpc.pw_xmlrpc [ oh ok and the server runs with python2.2, right? how database gnue involved in all this? yes python2.2 the problem is that the server runs with py_xmlrpc and the client with pw_xmlrpc which is not comptatible reinhard: how database gnue involved in all this? *** johannesV has quit IRC dimas, what do you mean with 'involved' ? dimas: it is not a matter of the db it is a matter of the xmlrpc connection between server and client reinhard: i can't imagine where i could miss to set them accordingly is that bug? dunno trying to find out now but telephone ringing every 5 minutes today.. johannesV_: there is #database = gnue in gnue.conf in gnue.conf, section [appserver] you can set database = foobar to define the backend-connection used by appserver if this is not defined there (like if it is commented out) it defaults to "gnue" so if not otherwise stated appserver uses a backend-connection called "gnue" you also specify the rpctype at the same place but if i define two new entries in connections.conf as described in hotline/README backend database would be used instead of gnue? *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** btami has quit IRC reinhard: server rpctype is initialized with xmlrpc.pw_xmlrpc dimas: to use another connections.conf entry instead of [gnue] you have to either use --database=connectionname or set database=connectionname in gnue.conf i use that, thanks for clarifying hotline README tells you to use --database, if you do this there is no need to change gnue.conf ok arrgh!! I am *blind* dimas: DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/py_xmlrpc/ClientAdapter.py", line 98, in _runMethod that should mean the *client* runs with py_xmlrpc instead of pw_xmlrpc so the problem seems to be the *client side* connections.conf how to force it to use pw_xmlrpc? you have an [appserver] section in connections.conf? that should contain an rpctype = line, too same syntax as in gnue.conf (or whatever connection name you use in your forms etc) *** lekma has joined #gnuenterprise hi all hi lekma *** wayneg has quit IRC reinhard: rpctype was set in connections.conf all this time to pw_xmlrpc? xmlrpc.pw_xmlrpc wait *** wayneg has joined #gnuenterprise you have an [appserver] section in connections.conf? that should contain an rpctype = line, too same syntax as in gnue.conf (or whatever connection name you use in your forms etc) generated forms use [appserver] entry, not whatever dimas: that depends on the call like: gfcvs appserver://foobar/form/some_class *** TSCHAK3 has quit IRC would use 'foobar' as appserver-connection *** TSCHAK3 has joined #gnuenterprise ok, so i had wrong setting for [appserver] rpctype johannesV_: error has changed :) does it work now? ah ok lol *** kilo has joined #gnuenterprise sorry, I should have spotted this much much earlier dimas, what kind of error do you get now ? DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/Base.py", line 232, in __call__ DB000: return self._adapter._runMethod (self._methodname, *args, **params) DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/pw_xmlrpc/ClientAdapter.py", line 101, in _runMethod DB000: raise errors.RemoteError, (exType, exName, exMessage, exDetail) DB000: gnue.common.apps.errors.RemoteError: isinstance() arg 2 must be a class, type, or tuple of classes and types johannesV_: it is with python2.2.2 and pw_xmlrpc python 2.2 also server side? yep same machine can you please type l$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.boolean what does this give for you? * johannesV_ was about to suggest just the same >>> xmlrpclib.boolean ah that's not good we assume this to be a 'Type' (like ) ok * reinhard thinks it really won't be too long anymore until we require python 2.3 until that many many kudos to dimas for reporting bugs and being patient with us :) how long do you think? or may be i dist-upgrade instead? dimas: please svn up and restart server if it's not useful for anyone else and tell me if it helped we aim at not requiring python 2.3 until sarge is released so gnue can always run on a current stable debian and well, sarge is about to be released RSN(tm) (for about a year now) RSN +- 2yrs ? also I think we've seen Mandrake with python 2.2 not too long ago so as long as you are willing to help us debug we are appreciating any bug report related to 2.2 problems DB001: 0:00:05.390 [GConnections:296] Attaching to DataObject (object) Error! Unknown step type "form" however if you want to go the easy way you can upgrade to 2.3 huh never saw *that* message just a sec DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/pw_xmlrpc/typeconv.py", line 128, in rpc_to_python DB000: return [rpc_to_python (element, exception) for element in value] DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/pw_xmlrpc/typeconv.py", line 96, in rpc_to_python DB000: return unicode (value, 'utf-8') DB000: UnicodeError: UTF-8 decoding error: invalid data the "unknown step type" seems to be from navigator yep next pasting - calling appserver form from command line dimas: is this with generated forms? yep can you please try a simple gfd form? ok, will load another db what about sample.gfd ? johannesV_: will set it now reinhard, johannesV_ : we're hitting a show stopper atm ie, being able to read not commited object ie, being able to read not yet commited object lekma: that's on the feature list as the very next item yep i've seen it was just to tell that we are going on, and report the actual pbs cool lekma, i know this is a real problem ... will do it next you're not having *too* big troubles with this problem, do you? *** wendall911 has joined #gnuenterprise * reinhard still feels responsible for talking lekma into using gnue reinhard: it's now a big pb reinhard: you don't have to * reinhard hopes lekma still thinks it was a good decision with simply gnue-common and forms it would'nt have been possible and I LOVE gnue-appserver :) the pb is now we're using every feature of it I think I will do a very last bugfix release for appserver today or tomorrow especially OnChange OnValidate and then johannesV_ can start on dirty reads as a first step to 0.4 so i still can svn up until tomorrow (before 0.4 starts)? yes ok actually you *should* as 0.3.4 contains a bad bug ?? making it impossible to call a procedure from another procedure that's why we need another bugfix release before 0.4 in the same class? not sure reinhard: simple forms working but you would have got an error message if you hit that bug :) dimas: thanks, good to know oh there was another thing someone told me, maybe it is a missing feature that can be added later the ability to have some kind of a cron inside appserver that will lauch nigtly jobs reinhard: how to set input encoding? like CLIENT_ENCODING for postgres mrp or picking lists creation i solve it actually by using cron and a external python script, that opens a session and execute proc but maybe it can be part of appserver (just an idea) lekma: actually the external python script is what we would consider the recommended way of doing it the idea of a cron function inside appserver was already there but I somehow don't like to reimplement things that are already there at least not as long as we have things with higher priority :) i understand dimas: for appserver? appserver *always* uses utf-8 bbl kids coming home reinhard: ok, what encoding would be used when i put non-latin text in entry? *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise dimas: forms uses whatever X is set to use (if in wx) or unicode (if in gtk2) then it's converted to utf-8 for xmlrpc transfer to appserver appserver converts to unicode for internal handling then converts to database client encoding according to connections.conf db backend then converts from client encoding to server encoding and stores in db easy, isn't it? ;-) hi reinhard: heh off now for real, will bbl hmmm, i remember it was about two months ago that i asked for find() operating on dirty objects... interesting thing is that everyone sometime finds the same thing problematic no offense, just thinking loud lekma: great to hear you have a working appserver project wel it's not over, but it's on its way performance issues? yep, a few of them, but controlled atm memory management in python seems sometimes strange i remember that, yes. can you give some numbers (how many concurrent users, etc) atm 10 users (with 5 sessions per users) which is about 50 sessions 10hours per day # of records? but each session generates thousands of transactions cause i generate xul forms we're not using gnue-forms but instead a xul/xmlrpc client and forms definitions are stored indb so each time you request smthing you have the overhead of form definition/generation and for complex forms you can feel it otherwise the project is quite small ah, i see with 3000 articles multiplied by 3 variants from memory 6000 real articles 1000 customers and around 4000 (only) order positions a year what makes it a bit difficult is the article variant thingy which has to be taken care of at each step (production/picking/shipping/invoicing) and the fact that appserver is a terra incognita :) yes, kinda pioneering thing *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** lekma has quit IRC ok back to work kilo: right, the fact that several people regarded dirty reads as an important missing feature made us move it upwards on the priority list dimas: you still here? dimas: the current traceback wrt unicode error when exactly does it happen? on form startup? here error happen when i try to commit non-latin data ah so form shows up correctly? yes ok what UI do you use? wx no gtk2 on that machine? no ok and committing non-latin data with gfd forms works? yep can you again try the gfcvs appserver://appserver/form/my_class?debug-file=foo.gfd and try if it works when you use *that* gfd that's dumped there? DB000: return [rpc_to_python (element, exception) for element in value] DB000: File "/home/ds/svn/gnue_head/.cvsdevelbase/gnue/common/rpc/drivers/xmlrpc/pw_xmlrpc/typeconv.py", line 97, in rpc_to_python DB000: return unicode (value, 'utf-8') DB000: UnicodeError: UTF-8 decoding error: invalid data and defug file is not saved at this point trying thiose saved before not saved? form shows up and debug file not saved? generated form not shows up at all ah oh sorry misunderstood you before reinhard: when exactly does it happen? reinhard: on form startup? dimas: here dimas: error happen when i try to commit non-latin data reinhard: ah reinhard: so form shows up correctly? dimas: yes so there is also an error with gfd forms? when you commit? it is with form from .gfd it shows error if commit non-latin ah ok can you please paste more of the traceback in a private window? *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise reinhard: great so there will be a release soon then? there will *always* be a release soon ;-) dimas: ok, thanks * reinhard thinks we have to add better debugging features to the TODO list for appserver... reinhard: commit non-latin works with py_xmlrpc well that's what I was just starting to suspect that python 2.2's builtin pw_xmlrpc isn't unicode enabled :( what about generated forms? reinhard: an interactive debugger ;) *** holycow has joined #gnuenterprise ok for the logs with python 2.2, pw_xmlrpc can't be used it is not unicode able again for the logs after a fix in form generator code, generated forms working again with python what we learned today is * always take care that you use same xmlrpc implementation on both sides * always check that you use a good encoding parameter in connections.conf for your db * with python 2.2, you have to use py_xmlrpc (package python-xmlrpc), you can't use python's native xmlrpc library (pw_xmlrpc) big kudos to dimas for all testing and patience :) off for today bye all *** reinhard has left #gnuenterprise and reinhard for leading testing and fixing bugs *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise bbl *** johannesV_ has quit IRC *** ra3vat has quit IRC *** mnemoc has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** sjc has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK2 has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** kilo has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK2 has quit IRC *** kilo has joined #gnuenterprise *** jamest has left #gnuenterprise *** kilo has quit IRC *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK3 has quit IRC *** TSCHAK3 has joined #gnuenterprise *** TSCHAK2 has joined #gnuenterprise *** TSCHAK3 has quit IRC *** jamest has joined #gnuenterprise *** jcater_ has joined #gnuenterprise *** jcater has quit IRC *** jcater has joined #gnuenterprise *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** titopbs has joined #gnuenterprise *** wendall911 has left #gnuenterprise *** sjc has quit IRC *** titopbs has quit IRC *** holycow has quit IRC *** mixi has joined #gnuenterprise *** mdean_ has joined #gnuenterprise *** mdean has quit IRC *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** mdean has quit IRC *** mdean has joined #gnuenterprise *** dcmwai has joined #gnuenterprise *** dcmwai has quit IRC *** jcater has quit IRC *** dcmwai has joined #gnuenterprise *** mixi has quit IRC *** TSCHAK2 has quit IRC *** TSCHAK2 has joined #gnuenterprise *** dcmwai has quit IRC