*** dimas has joined #gnuenterprise *** Amorphous has joined #gnuenterprise *** dcmwai has quit IRC *** btami has joined #gnuenterprise *** Morphous has quit IRC *** kilo has joined #gnuenterprise *** roche has left #gnuenterprise *** johannesV has joined #gnuenterprise *** btami has quit IRC *** reinhard has joined #gnuenterprise reinhard: hello *** btami has joined #gnuenterprise hi kilo, btami hi are you ready for debugging no real work at least until lunch :( ok. and what about johannes he's got a day off today wow ok i think i have minutes now kilo: you have any problems? aye i have a block-level trigger in a form, with no name given, a post-change trigger but it compiles wrong, and gives unknown executioncontext error observing python.py i discovered that the trigger function only gets a name ah no name identical to the block i think at least its name should be blockname_trigger-type_trigger-name so if no name is given, the trigger function name would be also unique it is of course true also when we discuss field-level triggers there is no need for the trigger function name to be unique AFAICT because the trigger function name only exists in the local function namespace but it is under-defined now as its name is only the block's name yeah i think the problem is if you have an unnamed trigger yes i think it's not the block's name but the trigger's name it gets the block's name so when you want to access a field in the block, it treats the name as a funciton not as a block... should i give an example? or is it understandble i think i understand ok i think the key lies in GTrigger.py lines 137 to 151 that's where the function name is built and that's where an element of the path is ignored if it has no name kilo: would you agree? hmmm seems so but imho blockname_triggertype_triggername would be the best way to name it or fieldname_triggertype_triggername i think i want to ask jamest about this we didn't change the way the trigger name is built we just changed the python adapter to *use* that name as a function name it might well be that there have always been triggers with empty "name" properties but it didn't have impact on the way the function worked yes, it was strange, because this form have always worked for me, and then this morning... but as far as we understand it correctly, you wrap trigger code in a function now I've committed a patch that always makes sure that there is a function name yes that is correct we had to do that to make parameters work but this function's name is not good, ie equals the blockname and return values it equals blockname_triggername but when the trigger has no "name" attribute it's only blockname yes, exactly OTOH the name of the function doesn't do much actually except in tracebacks, it won't appear anywhere the only problem happens if it is empty, so that python gets a syntax error kilo: if you svn up, it should work again at least but if it equals blockname, you cannot access block.something we should discuss with jamest what would be the optimal function name ok, svnupping now (wow, new english word...) kilo: that's correct i also agree that the name should be chosen differently just don't want to decide how exactly as i already have the feeling that i sometimes decide too much that affects forms and reports without having enough knowledge about what would be influenced by the decision :( i see. but this patch doesnt handle the case when several unnamed triggers are connected to the block or we should define that a trigger should have a name in all cases as designer doesn't allow to create it without name... kilo: every trigger has his own local namespace so the trigger name need not be unique among all triggers because the function is only defined in the local namespace (i think) ok, i will show you an example reinhard: there is 2 way 1. create unique names for wrapper function 2. triggers must have name so does the function name go in the global namespace? * reinhard doesn't really know, but always thought it'd go local # -*- coding: utf-8 -*- def blkKODSZOT (__namespace): for __add in __namespace.keys (): exec '%s = __namespace ["%s"]' % (__add, __add) del __add, __namespace dtsKODSZOT.createResultSet({'kodtip' : blkKODSZOT.fldKodtip.get()}) pass __result = blkKODSZOT (__namespace) it is the wrapper code for a POST-CHANGE trigger in the block i propose it should be named blkKODSZOT_POST-CHANGE so blkKODSZOT.fldKodtip.get would be interpreted correctly kilo: can there be only one trigger of a given type in a form? no, several ones ok, so the trigger name would still not be unique in one block you cannot have two identical typed triggers ah oh ok that's what i wanted to hear :) or in one field you cannot have two identical typed ones or better, you can put it in the xml file, but who konws what happens then... kilo: can you try something for me? yes of course what is the attribute for the type of the trigger? type="POST-CHANGE"? yes so actually in GTrigger.py after if p.name!=None: path=p.name+delim+path delim = "_" adding if p.type!=None: path=p.type+delim+path delim = "_" should do it would you also think so? maybe better if hasattr(p,'type') and p.type!=None: yes, it works! kilo: cool, thanks kilo: erm... do you have commit access? actually i was trying the same but i fscked up with indentation... not yet, should get any time, i posted the letter sometime err err i dont know ok then i'll commit it ok, thanks!!! reinhard for naming master!!! kilo: done ok reinhard: it rocks *** _florin_ has quit IRC *** rm-lunch has quit IRC *** rm-lunch has joined #gnuenterprise *** lekma has joined #gnuenterprise hello hi lekma hi reinhard *** dneighbo_ has joined #gnuenterprise just uploaded a new setup.exe for win32, please try/test it http://www.gnuenterprise.org/~btami/GNUe-Tools-0.5.3.99-svn5664-setup.exe bbl *** btami has quit IRC what should i do to translate common forms and appserver to french (what tools do i need, is there any doc about this on gnuenterprise.org)? lekma: what do you want to translate? *** dneighbo has quit IRC lekma: to get something like gnue-common/translations/fr ? lekma: you on gnu/linux? lekma: i have some wiki notes how i was doing that for russian brb on linux you need to xgettext from the src dir, that produces a .pot file then you edit it and make a .po file (with your favorite editor or poedit or kbabel or gtranslator) and whoops, there you are, ready to commit of course you can use msgfmt to check the .po for errors but all comes clear if you look at a makefile in a po directory anywhere in gnue back well the easiest way would be to erm the .pot file should already be there so you have to do actually nothing just download the latest nightly snapshot yes, just msgmerge, edit and done or am i wrong= ? but there is no .pot file generated now right you can use "make gnue-appserver.pot" for that would it be worth to generate it automatically and pu it in the snapshot? i think yes i think i'll change that *** lxf has joined #gnuenterprise it is ok for me but what is not ok: i remember jason committing some time ago in IIRC forms code and this commit also included all the .po files for forms that should be a no-go that was a bug in the makefile all po files were regenerated with setup-cvs.py i've fixed that long ago ok then even long before his commit actually these changes must have been there a long time before he committed them yes, i also think so. but they caused som eheadache for me, as i was just translating them yes i understand bbl *** kilo has quit IRC dimas: sorry i was away, i would like to translate menus, message,... in french i don't see any translation folder in gne-common reinhard: i use linux, but i can get my hands on a window box s/window/windows *** _florin_ has joined #gnuenterprise *** dsmith has joined #gnuenterprise lekma: then you should follow what kilo have said lekma: there should be a po/ folder in gnue-common reinhard: but all comes clear if you look at a makefile in a po directory anywhere in gnue dimas: ok reinhard: where is that makefile? reinhard: isee it now po/Makefile *** dsmith has quit IRC lekma: do you have a gnue-common.pot there? reinhard: in gnue-common/po there's no gnue-common.pot or did i misunderstood sthing lekma: ok, so you didn't use a snapshot, but you checked out svn, right? yes ok then in the po directory type "make gnue-common.pot" and see what happens cd ../src; pygettext --output=../po/gnue-common.pot `find * -name '*.py'` /bin/sh: line 1: pygettext: command not found make: *** [gnue-common.pot] Error 127 :) i will try to install pygettex pygettext should come with python cd clear oops wrong window lekma: what distro do you use? gentoo ah oh there are no packages, right? :) i mean not really no precompiled ones you say pygettext should be included with python or is it a separate pmodule i think it's part of python of course you could also wait about 3-4 hours we will do a prerelease then which will include ready-to-go .pot files because we planned that anyway for today ok but of course i can also help you through the potfile generation i can wait about the translation, and will try to find out more about pygettext in the meantime ok apart from that newer versions of gnu gettext can also handle python does svn work now? <_florin_> speaking of translations... how would you add support for new languages? <_florin_> just take a sample .po file and edit accordingly? _florin_: no * _florin_ newbie to i18n... _florin_: in every po directory, there is a *.pot file that is the .po template (thus the .pot) that is basically an "empty" translation <_florin_> in gnue-common/po there is no .pot file... you fill that in and save under the name de.po (for example) _florin_: the .pot file is included in our tarballs <_florin_> ah ok. if you checked out from svn you can go to the po directory and say "make gnue-common.pot" * reinhard has a feeling of deja-vu ;-) _florin_: you're from germany, correct? <_florin_> i live in germany. why? * reinhard just wondered which new language you wanted to add as we already have german <_florin_> i'm a native romanian speaker :-) ah yes i forget i'd sy say svn up and start the translation as you like we're doing a string freeze today so it's actually now or never :) <_florin_> hm... have to backup my tree files first -- they're not in svn yet. i got the .pot file by changing XGETTEXT = pygettext to XGETTEXT = xgettext --language=Python in the makefile <_florin_> don't want svn up to kill them <_florin_> i have some "unexpected token: +" errors. is that serious? i fixed them for common today <_florin_> ok :-) there might be some in forms and reports lekma: good :) _florin_: as i told lekma, we are aiming at a prerelease today <_florin_> ah what time? which you could download and that would contain a ready-to-go pot file depends on when jamest/jcater have time i hope in 2-3 hours <_florin_> don't wait for me -- i don't have a svn account anyway... <_florin_> i'll start translating some stuff <_florin_> maybe you can ship it with the next release :-) _florin_: the plan for the prerelease was actually make a prerelease for download today call for translations on the mailing list (and for tests of course) incorporate all translation files we get over the next 2 days make final release friday evening or saturday <_florin_> oh ok -- then maybe you get to see some romanian in gnue :-) that's how other projects do it at least that's good it would rock to see gnue translated into more languages <_florin_> no promisses though -- i'm translating just out of curiosity, but maybe that would kickstart some more translators :-) <_florin_> ok, have the new common .pot -- what now? edit and save as ro.po? _florin_: exactly you know the format of po files? (i guess yes) <_florin_> more or less... (rather less than more) well it's simple <_florin_> i figure that msgid is the english string and msgstr is the translation, right? apart from the header which you just fill in yes *** jamest has joined #gnuenterprise reinhard: dropdowns are wack <_florin_> is 'wack' good or bad? *** dsmith has joined #gnuenterprise they were patched about 6 weeks ago and the comments ( _florin_: bad) and look of the design don't match the behaviour at all but I'm not sure if this setup was a fix for wx on windows or what jamest: can we release in spite of that? or will it break too much? sure we can release and we can choose how we want it to work mouse/keyboard work but autocomplete is screwed or the current method *** joshua has joined #gnuenterprise i didn't want to rewrite it until I found out from btami (and kilo?) if this was a windows fix of some sort as what they were doing was ok, it just seems to expect events that are never sent a friend and I are going to try to form a business around gnue implementation here in India hi joshua have you been in here before? nope we decided to do this a few days ago gnue doesn't have any turn key packages that you could sell service on right away yah, i know i think/hope we're techie enough to handle it ok, i just don't want things mis-represented and it would be cool to fix some bugs and become a contributor as I do paid work using gnue solutions but not enough to make a living of it joshua: indeed it would be cool :) instead i'm forced to do a "real job" so i read the recent appserver_howto and i got some questions man unlike reinhard who owns his own business and only has to work 1/2 days i think we need to give SachaS a prize for doing this howto it seems to attract new contributors on a daily basis :) yah well we're thinking of getting into gnue consulting fulltime, if possible he even gets to pick the 12 hour block he gets to work each day jamest: roflmao actually i haven't even tried running gnue yet, just read docs and i'm wondering, should we build on the appserver or just use forms? or is the appserver required for any serious work? depends on the solution you are after say an inventory system, for starters *** dcmwai has joined #gnuenterprise * jamest will defer to reinhard to speak of what appserver adds to the equation well we got a prospect who is interested in working with us. they manufacture corrugated boxes i personally think appserver will be very nice addition soon but not had time to mess with it we're going to do the work for free, just to get credibility if you have experiances with databases yah, sure. the DB stuff is cake i design DBs in my sleep think of appserver as a database where you can write triggers and stored procedures in python instead of sql yah, sounds great. my only concern is stability if you find instabilities in appserver we will fix them the system has to work for real people in a relatively short amount of time what is short? short, uh .. well, they are working on paper now and they can't afford any expensive software so say a few months the current version number of appserver (0.0.6) might be too modest, but it has some kind of truth in it :) i mean, this is India right? so we probably have more time than i'm estimating cost is the main selling point ;-) i use appserver in production for 7 days now the issues i had were all non-appserver related whoa! really? it's probably good enough then but had to do with forms and reports (mainly because i had not enough knowledge there) yah well since everything is python it should be easy to debug god i hate c++ but my "production use" is a small application for 2 users reinhard: what?!?!? forms and reports are not perfect? (mainly because i had not enough knowledge there) :) yah well our first prospect is only gonna have 2 users ;-) well personally i would dare to use appserver there especially when i remember where we stood with appserver 2 months ago ok, and appserver is the future so might as well get cooking where we stand now and where we can extrapolate to be in 2 months approximately :) one thing about gnue is, correct me if I'm wrong reinhard' but if your front end is in gnue-forms and appserver starts to give you trouble, you can switch to direct access of the tables (2 tier) without much effort as I believe appserver objects map directly to table structures plus an administrative field or two? then you could deal w/ forms issues instead :) jamest: you could do that if you didn't use the features appserver gave you but if you have procedures in appserver you will of course lose them yes you'd have to convert to batch processing if possible yeah ok, we better get started then SAP is gonna be toast jamest: ok, so will we push out a prerelease today? if you read the logs we had volunteers from french and romanian translations popping up today :) s/from/for/ i'm ok with that which way we want dropdowns to work? the current way? i don't mind i've gotten used to use the keyboard *** joshua has quit IRC *** holycow has joined #gnuenterprise i've just updated all manpages and dtd's jamest: could you please create the tarballs? make sure that MANIFEST doesn't exist and GNUE_VERSION_SUFFIX=-pre1 ./setup.py sdist --format='gztar,zip' it should be done on sarge or sid because pygettext on woody is broken (and i have only woody :() *** johannesV_ has joined #gnuenterprise *** johannesV has quit IRC reinhard: yes, the nightlies don't already do that? jamest: the nightlies do exactly that except they use another suffix ok i'll be a bit or do we have a checkout on ash i can svn up and make the tarballs? *** Vee has joined #gnuenterprise there is the working copy in /usr/local/gnue-sandbox iirc but i can do in a few i'm just "debating" with some co workers atm ok thanks *** jcater has joined #gnuenterprise reinhard: we have some trouble with appaserver s/appaserver/appserver File "/usr/local/gnue-svn/gnue/gnue-common/.cvsdevelbase/gnue/appserver/classrep/Base.py", line 253, in __getitem__', ' raise self._itemNotFoundError (key)', "PropertyNotFoundError: Class 'kiki_juju' has no property 'kiki_rtext'", '' but there is a module 'kiki', a class 'juju', and a property 'rext' s/'rext'/'rtext' and evrything seems good in the db i.e. we have table kiki_juju with fields gnue_id and kiki_rtext do you have the entries in the gnue_properties table ? yep but as 'rText' ie the way we created it with classrepository.gfd ggcvs gsscvs must have change it