jamest (foobar@adsl-66-142-221-144.dsl.tpkaks.swbell.net) left irc: "Client exiting" bddebian (~bddebian@ip68-4-154-50.oc.oc.cox.net) joined #gnuenterprise. hi heya ajmitch!! holycow (~rtaylor@24.86.227.162) joined #gnuenterprise. holycow (~rtaylor@24.86.227.162) left irc: Read error: 60 (Operation timed out) holycow (~rtaylor@24.86.227.162) joined #gnuenterprise. reinhard (~reinhard@M1250P006.adsl.highway.telekom.at) joined #gnuenterprise. johannesV (~johannes@M1554P008.adsl.highway.telekom.at) joined #gnuenterprise. sjc (~sjc@cpc2-seve3-4-0-cust112.popl.cable.ntl.com) joined #gnuenterprise. holycow (~rtaylor@24.86.227.162) left irc: Remote closed the connection btami (~btami@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. bddebian (~bddebian@ip68-4-154-50.oc.oc.cox.net) left irc: "Client exiting" thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) joined #gnuenterprise. morning guers good monring thierry guten morgen reinhard chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) left irc: Read error: 110 (Connection timed out) gsoti_away (~gsoti@adsl-68-72-165-244.dsl.chcgil.ameritech.net) left #gnuenterprise. thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) left irc: Read error: 110 (Connection timed out) thierry (~thierry@AStrasbourg-251-1-1-7.w82-127.abo.wanadoo.fr) joined #gnuenterprise. johannesV (~johannes@M1554P008.adsl.highway.telekom.at) left irc: Remote closed the connection dimas (~ds@195.218.177.46) joined #gnuenterprise. gsoti_away (~gsoti@adsl-68-72-103-16.dsl.chcgil.ameritech.net) joined #gnuenterprise. dsmith (lnpje6hfdh@oh-strongsvillecadent1-1f-100.clvhoh.adelphia.net) joined #gnuenterprise. jamest (~jamest@gw.math.ksu.edu) joined #gnuenterprise. btami (~btami@ip102-205.ktv.tiszanet.hu) left irc: "Leaving" chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) joined #gnuenterprise. chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) left irc: Client Quit chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) joined #gnuenterprise. chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) left irc: Client Quit chillywilly (~danielb@CPE-24-167-201-211.wi.rr.com) joined #gnuenterprise. mdupont (~mdupont@pD9E265B5.dip.t-dialin.net) joined #gnuenterprise. jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. good morning america i've got a question Action: reinhard can't keep his hands off gnue-common you feind! i'd like to do the checktype() stuff take your dirty paws off her basically i need to implement at least a stub of the exception class hierarchy for that now i'm not sure where to put that stuff first i considered common/apps but i would like this stuff to be available even when you don't use GBaseApp et al so actually i don't think it should belong into the apps package i consider making a seperate module in common like from gnue.common import exceptions or even from gnue.common.exceptions import * and you have everything like EGnueBase EGnueInternalError etc and of course also checktype () for logical reasons i'd think checktype() should be in the same module as the exception classes what do you think? reinhard: actually, if you look in gnue-common/module/base/__init__.py it initializes the .apps stuff automatically to create, f.e., _(), etc so if you import gnue you automatically have those stubs oh ah (and of course you have to import gnue to get to any other gnue libraries) imho that's where checktype should go so you'd add checktype to the __builtins__ dict? I think so ok what were you thinking? the same ok what about the exceptions? I like the idea of gnue.common.exceptions ok fwiw, if you want checktype in exceptions you could do the same thing in base/__init__.py for that exceptions module we still have to agree on the exception tree I'm just thinking I'd like it to automatically be available to every module w/o them having to import stuff jcater: i agree very much with you acutally i always wanted it in __builtins__ but i feared you wouldn't like to put too much stuff there I don't think we should overcrowd __builtins__ but this makes sense now, as you propose it yourself, i am all for it :) ok you remind me of my wife "make him think it was his idea, and he'll go for it" is that good or bad? jamest (~jamest@gw.math.ksu.edu) left irc: Remote closed the connection oh ok :) so common/apps/__init__.py would actually be the better place to init i18n, too? (now it's in common/apps/GBaseApp.py) jamest (~jamest@gw.math.ksu.edu) joined #gnuenterprise. dneighbo (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise. hmmm i suppose not answering means that he agrees ;-) sorry users j/k reinhard: possibly if you guys are getting rid of the textEncoding thing if not, you can't access the gconfig stuff until after the app initializes nit of it err but if it's based on locale now then I'd say, yes, that's a logical place to init it doesn't use textEncoding the use of textEncoding was causing troubles anyway ok if it doesn't depend on gconfig any more, then I'd say yes because for example error messages when loading the config file already were marked for translation but they couldn't be translated because the config wasn't loaded :) ok derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: Read error: 110 (Connection timed out) reinhard: mkdir: cannot create directory `/home/jason/gnue/share/locale/lt': File exists ln: creating symbolic link `/home/jason/gnue/share/locale/lt/LC_MESSAGES/gnue-reports.mo' to `/home/jason/cvs/gnue/gnue-reports/po/lt.gmo': No such file or directory mkdir: cannot create directory `/home/jason/gnue/share/locale/ru': File exists ln: creating symbolic link `/home/jason/gnue/share/locale/ru/LC_MESSAGES/gnue-reports.mo' to `/home/jason/cvs/gnue/gnue-reports/po/ru.gmo': No such file or directory is that normal ? did you svn update gnue-reports? or only gnue-common? I svn updated from gnue/ ok in gnue-reports/po do you have .gmo files there? yes hmm can you try to rm -rf /home/jason/gnue/share/locale and re-run setup-cvs.py? (i figured your error message is from setup-cvs.py) that fixed it :x hmmm we could include that in setup-cvs.py done reinhard: I'm horrible with makefiles but de: 62 translated messages, 19 fuzzy translations, 213 untranslated messages. es_MX: msgfmt: es_MX.po: warning: Charset "iso8859-13" is not a portable encoding name. Message conversion to user's charset might not work. 142 translated messages, 32 fuzzy translations, 120 untranslated messages. es_MX gives a warning which throws off the STATISTICS but I think you on woody? no sid LANGUAGE=C msgfmt --statistics --output-file=$@ $< 2>> STATISTICS is there some way to 'grep "translated"' the output of msgfmt ? johannesV (~johannes@M1554P008.adsl.highway.telekom.at) joined #gnuenterprise. jcater: sure I think that'll fix it in woody, the warning is printed to stdout so didn't affect stderr hmm wait is there such a thing like 2| to pipe stderr to another process? hmm in scripts I do (cmd .... 2>&1) | grep translated > STATISTICS sounds reasonable but not sure how that works in makefile you can do exactly the same in a makefile jcater: can you please try it for me? cause i can't reproduce the effect on my woody lol Action: jamest only read the last line rofl wasn't sure I was in #gnuenterprise or not anymore perfect I'll commit jcater: there are 6 po/ directories all of them have the identical makefile except for a single line (the first line) would be great if you could change all of them done appserver, common, forms, reports, designer, navigator great thanks a lot Sacha (~Sacha@80.248.200.11) joined #gnuenterprise. hi everyone howdy reinhard: are the po files committed in svn? generally yes I just committed the Makefiles but it committed a long list of po files but if you didn't make changes, you needn't commit them from where I ran setup-cvs.py well the po files just a sec well the po files contain all orignial messages with the according translations so there are 2 reasons why a po file can change a) a translator changed translations b) an evil coder changed/introduced/deleted a translatable message or however for b) to get into effect "make" in the po directory has to be run c) sid's msgfmt produces a slightly different gmo format than woody's no it's the po files err crap so it just would be you're right Action: jcater wasn't thinking sid's pygettext would produce a different po format could be bah if our commit emails were working I'd look at the diff it generated isn't there a svn history command or something? ah, blame i found out already pygettext sid generates basically the same file but sorts entries in a different order :(( well, fudge however seriously the sid order is *much* more logical than the woody one and from now on i guess we won't commit too often in the po dir not sure though what's the best way to handle it johannesV (~johannes@M1554P008.adsl.highway.telekom.at) left irc: "Client Exiting" what is the license of pygettext? an option is to always include "the" gnue version in gnue-common/utils so everyone runs the same script not necessarily an ideal solution but a solution acutally, license permitting, that may not be a bad idea pygettext comes with python ah i think of other possibilities like regenerating the po files only on special request and on setup-cvs.py only generate gmo from the po version that is in cvs i think that would be even better yeah reinhard: would it be worth changing the po/Makefile's to just have two lines DOMAIN=gnue- then calling a central Makefile that does the rest one stored somewhere in gnue-common? as it seems like only the first line of all those are different Action: jcater doesn't really care, but is just thinking of maintenance jamest (~jamest@gw.math.ksu.edu) left irc: Remote closed the connection i like things being more self-contained ok and i don't think there will be many changes in the makefile once the thing runs nicely i think i'll change it the way i said above bbl jamest (~jamest@gw.math.ksu.edu) joined #gnuenterprise. siesel (~jan@218-162-232-105.HINET-IP.hinet.net) joined #gnuenterprise. jcater: if "make gmo" leaves the .po files alone and just generated .gmo from existing .po and "make" generates *.pot, regenerates *.po and generates *.gmo then and setup-cvs.py would only call "make gmo" would that make sense? gsoti_away (~gsoti@adsl-68-72-103-16.dsl.chcgil.ameritech.net) left #gnuenterprise. (while "setup.py sdist" would do "make" to generate current .po-files) hey what module contains the generic Error exception? exceptions module? exceptions.Error bleh... in this case you would also have to run "make" manually in the po/ directory to generate the STATISTICS file but the STATISTICS file would also be included in the release reinhard: I would seperate "make" as you described it into make pot and make gmo there is no such exception bleh siesel: ok but a single "make" should just call make gmo, as the make pot step possibly changes a lot stuff ok and probably is just needed short before a release so then setup.py sdist would call "make pot"? i'm sure jbailey would like that ;-) well every translator needs it if he wants to work on a translation probably setup.py build would call it but he always can do for example "make de.po" but I'm not shure about that dsmith (lnpje6hfdh@oh-strongsvillecadent1-1f-100.clvhoh.adelphia.net) left irc: Remote closed the connection make de.po would be nice :) that works anyway well not that it fills in the translation automatically of course :-) :) Sacha (~Sacha@80.248.200.11) left irc: Read error: 110 (Connection timed out) dsmith (uxxbjgvoy2@oh-strongsvillecadent1-1f-100.clvhoh.adelphia.net) joined #gnuenterprise. dimas (~ds@195.218.177.46) left irc: "Вышел из XChat" jcater: i was wrong the STATISTICS is gonna be generated on setup-cvs.py but it will not be up to date as it will only respect the translatable messages that are already in the existing .po files but in any case the STATISTICS for releases will be up to date anyone know why running a script as root and using os.mkdir I would get permission denied? I can create the same damn directory from the shell makes no sense chillywilly: no idea chillywilly: Run it under strace. chillywilly: Maybe with a -f option not very helpful It should show you what syscall is failing, and with what error code. it's saying the same thing calls mkdir() then says permission denied' SHould also show you what user is being swithced to (if any) hmmm what's the current directory? (at the time the script is runnign) /var/mail/vdomains/setup fyi, /var/mail is setgid mail man this terminal is fscked up bleh ,--8<- |setresgid32(0xffffffff, 0x66, 0xffffffff) = 0 |setresuid32(0xffffffff, 0x8, 0xffffffff) = 0 `-->8- whatever that shit means it's hex sonot the easiest to interpret "If one of the parameters equals -1, the corresponding value is not changed." From man setresuid reinhard: can it be that you removed the textencoding setting? ummm wth is -1 in hex? All ones 0xffffffff 0x66 -> 102 I see yea 'Debian-exim user and mail group ah, duh calls setegid and crap doh I have it backwards too siesel: from where? siesel: btw not sure if you noticed if you look where dumpXML is called it seems that dumpXML is expected to return UnicodeType jcater: .po files are only rebuilt now on "make update-po" reinhard: from the part which is i18n.py now reinhard: cool reinhard: the commit message is wrong it should be input encoding ah ok siesel: we agreed to use the encoding from the user's locale settings if yes, then I misunderstood something as input/output encoding is defined by textencoding at the moment we have to totally remove it or continue use it, but it has to be consistent well I use it regulary, so I would like to keep it, but I'm ok with having it default to f.e. None, which means, that it will be replaced by the locale setting that was the starting point of the discussion actually *why* we have textencoding and don't use the current locale's setting apart from that textEncoding is used for many things that are IMHO quite unrelated for example just that i use iso latin 1 as my local encoding doesn't mean that i want designer to save my gfd's in latin1 btw textEncoding isn't used in *that* many places (last time i looked) and some of them even will be removed if all code is unicode-cleaned and we talked about the o() function which converts unicode to the local encoding reinhard: I reread the log from two days before and can confirm that we didn't come to a decision about the locale/textConfig point chillywilly: Are you happenin now? ok then yes, its textConfig is used at many different places and its not used very consistently dsmith: yea, fixed the script Groovy. siesel: it's used 45 times chillywilly: What was it? and probably we have to introduce some more settings, like f.e. a setting to save files in dsmith: had rthe variables GID and UID globals switched and the script does an os.setegid, os.seteuid any application on any posix like system honors the user's locale settings for encoding i think it would be just wrong if we didn't dsmith: they had the wrong values jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) left irc: Remote closed the connection but locale encoding is sometimes bound to the locale a bit too close. if I want to have a different encoding, but the language and the encoding aren't used together very often I get problems over problems can you give me an example? o() as I understood it should take gConfig(textEncoding) as the basis jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. f.e. even de_DE.UTF-8 only doesn't work with many applications, and some chinese encodings are still broken in X11 and quite unusable as locale so I want to have the possibilty to split the locale and the language setting from each other f.e. to use locale A and use font X with locale B in wx windows but then you will get problems I mean encoding B in wx windows most probably for example any messages generated by non-gnue code (for example the dbsig drivers) will output the "wrong" encoding apart from that using gConfig in _() will break translation in some respect (like it was broken before) in what respect? _() in module initialization code will not work (as config isn't loaded yet) arturas introduced a pseudo _() that was a placeholder until the real _() was loaded after configuration its possible to do a i18n.encoding=gConfig("textEncoding") in GBaseApp that would be an option but then, the encoding will be different for messages before and after that point yes, but that's something I can live with. ok i can live with that, too (i think) but then we have to deprecate textEncoding for normal use SachaS (~sacha@80.248.200.11) joined #gnuenterprise. that *normally* the user's setting is valid IMHO it shouldn't in 90% of the cases, but there are still 10% were it is useful i might have a user working with latin1 and another user that uses utf8 as his local encoding IMHO for both of them gnue should work without having different config files yes, textEncoding should default to "" which means that its overwriten by the standart locale or even that it doesn't overwrite i18n.encoding, then we just have to replace the cases where textConfig is used by i18n.encoding i'd say textEncoding should default to which means local encoding ok. that means "None" most of the cases where textEncoding is used it shouldn't be used actually anyway IMHO btw. can I do a recursive grep I mean, do you know how to do? find . -name "*.py" | xargs grep "textEncoding" or if you want it in short find . -name "*.py" | xargs grep "textEncoding" | wc --lines ok. seems like we need an encoding setting for the following cases: 1. encoding of input and output streams to the console 2. encoding for newly created files (reports and designer) 3. basic encoding of database input output, if not defined otherwise in connection.conf 4. encoding of input/output of GUI if it doesn't have unicode support hi you crazy guys :) i wonder where you get the stamina to code and code and code :) Action: SachaS thinks they must be real geeks SachaS: we are :) :) siesel: for 2, i would propose to use unicode generally except for special cases where it should be overridden in program invocation (not by config setting) these files should be portable 1. should probably be locale encoding in any case not sure if we want 3. in gnue.conf at all (or if we should force the user to set it in connections.conf) because it's 100% db specific and for 4. i think it would be best to find out what encoding the used font uses :) (my 2 cents) in any case, i think it's wrong to use a single setting for all 4 siesel (~jan@218-162-232-105.HINET-IP.hinet.net) got netsplit. i scared him off :( siesel (~jan@218-162-232-105.HINET-IP.hinet.net) got lost in the net-split. siesel (~jan@218-162-232-105.HINET-IP.hinet.net) joined #gnuenterprise. no, I just lost wlan connection yes, I thought so too first, but what if you want to edit the file per hand afterwards? ok, who does this should know how to switch to unicode mode. ok, I'm ok with unicode for 2. although a special setting for 4. would be nice in some cases (de_DE.UTF8 as locale), I think the effect can be get with textEncoding too