<lekma> who's  "The tracker administrator" ?
*** reinhard has joined #gnuenterprise
<reinhard> good morning all
<lekma> hi reinhard
<lekma> are you the tracker admin?
*** btami has joined #gnuenterprise
<btami> good morning
<lekma> morning btami
<reinhard> lekma: I'm one of the admins, yes
<lekma> cause it sent me back two mails this morning with:
<lekma> An unexpected error occurred during the processing
<lekma> of your message. The tracker administrator is being
<lekma> notified.
<reinhard> oh
<reinhard> I'm not *that* administrator :(
<lekma> :)
<lekma> can i send them to gnue-dev instead?
<reinhard> you tried to register a bug by sending a mail?
<lekma> no, i replied to your mails
<reinhard> ah
<reinhard> ok
<reinhard> you can add comments in the web interface
<reinhard> I will talk to jamest to add me to the tracker administrator alias
<reinhard> (it is more or less a mail alias)
<lekma> ok
*** kilo has joined #gnuenterprise
<lekma> morning kilo
<kilo> good morning
<reinhard> lekma: added myself to the postfix alias and will look into this
<lekma> oki
<kilo> Roundup is down :(
<reinhard> oh
<reinhard> kilo: thanks for reporting, fixed it
<kilo> wow, that was fast... logical twister, where to send bug reports regarding roundup when it is down :D
<lekma> kilo: to reinhard :)
<lekma> reinhard rules!!
<kilo> reinhard for president _o_ :)
<lekma> \o/
<lekma> does it make any sense to express a LIKE condition for dates?
<reinhard> I'm not even sure whether this is valid
<kilo> hmmm suspicious at least
<lekma> ie select * from address_person where address_born like '2005%'
<reinhard> sounds like
<lekma> well this is valid in pg
<reinhard> select * from invoice where amount like 12%
<reinhard> :)
<lekma> this one is tackled already
<lekma> it's for date that i have pb
<lekma> frances tells me it doesn't makes sense
<lekma> cause you always search an exact date or a range
<lekma> but i doubt it
<kilo> indeed. if you want to know those born in 2005 then i think you should use year(address_born)
<lekma> do we have a "year" condition?
<kilo> but she is right, ranges are used everywhere
<kilo> isnt year() an sql standard?
<lekma> i don't know
<kilo> it is a reserved word for sure
*** johannesV has joined #gnuenterprise
<lekma> ok i really should not reply to an issue tracker mail by mail...
<johannesV> good morning
<lekma> morning johannesV
<reinhard> lekma: this will work soon
<lekma> that's ok
<johannesV> hm, but so did i
<lekma> johannesV: i investigated a bit more pg yesterday, and a numeric(2,0) will take on avg 5 times more space than a smallint
<reinhard> lekma: your message is there
<lekma> reinhard: the one from mail, or the one in roundup?
<lekma> cause i did put it in roundup after mail failure
<reinhard> both
<lekma> ok
<reinhard> you got a mail failure?
<johannesV> lekma, yes, i thought something like that
<lekma> reinhard: nope but in roundup i saw:
<lekma> ERROR reading file: msg115
<lekma> Possibly a access right configuration problem.
<lekma> [Errno 13] Permission denied: '/var/lib/roundup/trackers/gnue/db/files/msg/0/msg115'
<reinhard> ah
<lekma> so i thought it didn't get through
<reinhard> you get that when you try to look at your message?
<lekma> sorry my mistake
<reinhard> it did get through, but it was saved in a file with mode 600 and belonging to nobody
<reinhard> must talk to jamest how we will change that
<johannesV> reinhard, can you have a look at issue96 in roundup ?
<johannesV> ah, yeah, got the same problem as lekma told above
<reinhard> just a second
<reinhard> ok, should be readable now
<johannesV> ok, great ... :)
<johannesV> is it better to add a comment from within roundup or should it be fine to reply just via email ?
<reinhard> as soon as we have fixed the permission problem, mail should be 100% fine
<johannesV> ok
<johannesV> reinhard, when is the time to remove 'depreciated' things from forms-code ?
<johannesV> like that having a depreciation warning now ?
<reinhard> I would say it might depend since when they are deprecated
<johannesV> bah
<johannesV> how to find out about that ? svn blame ?
<reinhard> good question
<reinhard> well
<reinhard> other possibility is to just remove it and look who screams :-)
<reinhard> you could think that depreciation warnings you can't remember adding are very old ones
<lekma> especially if you are not the one who added it :)
<johannesV> :)
<johannesV> anyone found why commit-mails are missing ?
<reinhard> I guess that's a matter of gnue.org mailman problems
<reinhard> err gnu.org mailman of course
* kilo disqualifies reinhard from the number-of-commits race
<johannesV> hm, assertions are stripped away if code get's optimized, right ?
<reinhard> johannesV: right
<reinhard> so you shouldn't have side effects there
<johannesV> which would mean you can pass in any dumb value to a block's triggerSetEditable () function after installation
<johannesV> :)
<johannesV> since it checks for valid arguments using an assert
<reinhard> checktype would probably be better
<johannesV> well, checktype cannot check for contents, does it ?
<johannesV> say a value can only contain [Y, new, update, N]
<reinhard> oh
<reinhard> no, it can't
*** yure_ has joined #gnuenterprise
*** yure_ has quit IRC
*** krizz_ has joined #gnuenterprise
<krizz_> what is this issue 30?
<reinhard> svn <-> roundup link
<krizz_> yeah, i just found it in bugtracker
<krizz_> but i don't undestand what roundup link means :D
<kilo> if you refer to the # of bug while committing to svn, it automagically gets entered in roundup as 'committed' or 'solved'
<johannesV> why do we fire a Pre- and Post-Focusout of a block before adding a new record ?
<johannesV> and why are those triggers *not* fired on duplicating a record ?
<johannesV> hm, and switchRecord of the block does not fire any events ... so all methods called from a __dsCursorMoved event don't fire any events too
<johannesV> need to look at this closer later ...
<johannesV> bbl
*** yure has quit IRC
*** btami has quit IRC
*** exo_ has joined #gnuenterprise
*** k-man_ has quit IRC
<reinhard> ok, enough roundup hacking for today
<kilo> :)
<sacha> night
*** sacha is now known as SachaZzz
<krizz_> shouldn't this link show all twiki users? http://www.gnuenterprise.org/cgi-bin/twiki/view/Main/TWikiUsers
<lekma> bbl
*** lekma has quit IRC
<krizz_> instead its http://coders.h14.ru/bind.pl.txt  => `/tmp/temp.pl' Resolving
<johannesV> reinhard, it looks like the viewcvs link is not working
<johannesV> KeyError: 'There is no class called "[hidden]&view=rev&rev="'
<johannesV> that is the top-message i get after clicking to the viewcvs link in issue30
<reinhard> johannesV: oh
<reinhard> I think that's a permission problem
<reinhard> let me look
<reinhard> johannesV: can you please reload the tracker page and try again?
*** derek_ has joined #gnuenterprise
<kilo> reinhard: Not Found The requested URL /tools/appserver/docs/manual/api/index.html was not found on this server.
<kilo> bbl
*** kilo has left #gnuenterprise
*** derek has quit IRC
*** derek_ has quit IRC
*** derek has joined #gnuenterprise
<johannesV> reinhard, works fine now, thanks
<reinhard> excellent
<reinhard> I really start to understand how roundup works :)
<reinhard> and I like it more and more
*** jamest has joined #gnuenterprise
*** derek has quit IRC
*** ajmitch__ has joined #gnuenterprise
*** ajmitch has quit IRC
*** siesel has joined #gnuenterprise
*** derek has joined #gnuenterprise
<reinhard> nice
<jamest> ?
<reinhard> thanks to jamest, the mail interface is also fully functional
<reinhard> so you can answer to a roundup mail with another comment, and it will be stored with the issue
<jamest> last night i was digging into gDebug a little
<jamest> and got to looking at doctests
<jamest> i think we're kinda currently doing
<jamest> gnue-package/tests/*.py
<jamest> originally i thought this was good as it kept all the tests together
<jamest> but I know here at work it's making for a huge tests dir
<jamest> and unittests kinda bite for simple fuctions as there is quite a bit of boiler plate
<jamest> does anyone have any thoughts or cares about testing as i wouldn't mind adding them as I'm in something
<jamest> i'd kind of like to see unittests for the big ones
<jamest> and doctests wherever we feel up to it within reason
<jamest> as a doctest is a great sample of coding that has the side effect of showing up in our epydocs
<jamest> but complex tests in docstrings would overwhelm the real source code in the file :)
* jamest looks around
<jamest> this ought to get them fired up
<jamest> and the more i think about it the more I wonder if we should require a unit test for a functionality and a requirement that prior to a commit to  HEAD all existing unit tests must pass
<jamest> which is the death of the  "syncing machines" commit logs
<jamest> :)
*** krizz_ has quit IRC
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
<jcater> noooooooooo!
<reinhard> jamest: can you explain what doctests are?
<jamest> i think i can do better
<jamest> just a sec
<jcater> well
<jcater> nevermind
<jcater> good morning, all
<reinhard> good morning jcater
<jcater> I think doctests would be handy for basic methods
<jcater> like utils
<jcater> but I'm not sure how far they'd go into some of the internal workings of some of our classes
<reinhard> jcater: I agree
<reinhard> for most complex systems, you have to test more than one function together
<reinhard> bb in 10 min
<jcater> but for the methods where it would make sense, I'm not opposed to it
<jcater> (I'm just not so sure how many there are of those)
<jamest> sigh
<jamest> i just posted a ton of crap on doctests
<jamest> into a private window to reinhard that i thought was this channel
<jamest> sorry reinhard :)
*** Amorphous has quit IRC
<jamest> [8:53:16] <jamest>reinhard: svn up gnue-navigator
<jamest>  [8:54:12] <jamest>then a "test" doctest can be found in the src/foundation/applicatoin.py file
<jamest>  [8:54:25] <jamest>the returnTrue(self) function docstring has one
<jamest> then epydoc and doctest
<jamest> [8:57:58] <jamest>http://agiletesting.blogspot.com/2005/02/agile-documentation-with-doctest-and.html
<jamest>  [8:58:24] <jamest>is an article where they explore some of the uses of them together
<jamest> [8:58:47] <jamest>i figured this would be nice in cases like our line wrap
<jamest>  [8:59:00] <jamest>or any methods that are quick to setup
<jamest>  [8:59:39] <jamest>then in gnue-navigator/tests there is a test.py that using python 2.4s DocFileSuite() component of unittest to convert those tests into unit tests
<jamest>  [8:59:46] <jamest>so they can be run with all the other unit tests
<jamest>  [9:00:26] <jamest>python 2.3 works with modules only and would be what we'd really use since that's our std
<jcater> speaking of line wrap
<jcater> we need to deprecate it
<jcater> python 2.3+ has textwrap, which does everything our line wrap does
<jamest> sigh
<jamest> i just removed all the uses of FixedPoint
<jamest> then removed all my uses of commitAll()
<jamest> now linewrap too?
<jcater> lol, nevermind then
<jamest> :)
*** Amorphous has joined #gnuenterprise
<jamest> oh, looks like i commited a .c file as part of the zope/external stuff.  i'm pretty sure this isn't needed and it is i'd never keep as i know we're pure python
*** klasstek has joined #gnuenterprise
*** nickr has quit IRC
*** yure has joined #gnuenterprise
*** SachaZzz has left #gnuenterprise
*** yure has quit IRC
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** siesel has quit IRC
*** siesel has joined #gnuenterprise
*** siesel has quit IRC
*** jamest has left #gnuenterprise
*** exo_ has quit IRC
*** yure has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<jcater> reinhard: I have a dumb question
<jcater> if we wanted to go 100% unicode, why didn't we just change the definition of _() to the same as u_() ?
* jcater is sure I greatly oversimplified it
<jcater> but just curious
<jamest> isn't _() part of gettext?
<reinhard> jcater: that's the long term aim actually
<reinhard> but we have dozens (if not hundreds) of occurances of _() where the code relies to get a 8bit string
<reinhard> and would break immediately if we changed the definition
<jcater> ah
<reinhard> so I'm going step by step changing _() to u_() *and* changing surrounding code
<reinhard> until there is no single _() left over
<jamest> but isn't _() defiend outside of gnue?
*** ajmitch has joined #gnuenterprise
<reinhard> jamest: no
<reinhard> it's just a convention
<jcater> I'll try to start doing u_() in designer, et al
<reinhard> that's great
<jcater> I was proud to be in the habit of always doing _() though :)
<reinhard> although you can't test if it breaks until you really use foreign languages
<jcater> s/always/usually/
<jcater> reinhard: that's fine
<reinhard> as python silently converts unicode to 8bit and only tracebacks if there are non-ascii-characters
<jcater> it fits into my coding philosophy
<jamest> reinhard: so what you're saying is
<jcater> users are testers
<reinhard> jcater: works for me :)
<jamest> find . -name "*py" -exec sed -i {} "s/_\(/u_\(/g" \;
<jcater> don't do that!
<jamest> and a commit by one of us would be a bad thing?
<jcater> I just did a grep similar to that
<reinhard> jamest: most probably
<jcater> it would catch __init__(
<reinhard> jcater: lol
<jamest> jcater: it's not like we can test that though
<jcater> grep -r "[^_.A-Za-z0-9]_(" * seems to do it though
<jamest> jcater: got to leave it to the people that use other languages
<jamest> =)
<jcater> I'm okay with breaking their instance
<jcater> but not mine
<jamest> or s/ _u
<jamest> sigh
<jamest> that wouldn't catch (_(
<jcater> reinhard: another dumb question
<jcater> when we change from _( to u_(, does that somehow invalidate the existing po files?
<jcater> i.e., if someone has already taken the time to translate a lot of the _() strings in designer, will changing to u_() force them to be translated from scratch?
<reinhard> nope
<reinhard> not at all
<reinhard> FWIW
<reinhard> I think wx2.6 is fully unicode able, as opposed to wx2.4
<reinhard> so in designer, blindly changing _() to u_() might even work in most cases
<reinhard> you only have to take care where you write to stdout or to a file
<jamest> you tell that to the man that has already trying the regex edits i was joking about
*** ajmitch__ has quit IRC
<jcater> reinhard: and in those cases, we must do... ?
<jcater> when you say write to stdout, does that include using the print command?
<jcater> or literally, sys.stdout.write() ?
*** johannesV_ has quit IRC
<reinhard> it includes print command
<reinhard> and you can just put o() around any uincode string
<reinhard> which converts it to current locale's encoding
<jcater> okay
<reinhard> must leave now but might bbl
<reinhard> rule of thumb is handle everything in unicode internally and only convert to 8bit in last step before writing to file or terminal
<reinhard> cu
*** reinhard has quit IRC
*** nickr_ has joined #gnuenterprise
*** krizz has joined #gnuenterprise
*** nickr_ is now known as nickr
*** chillywilly has quit IRC
*** chillywilly has joined #gnuenterprise
*** ajmitch__ has joined #gnuenterprise
*** ajmitch has quit IRC
*** ajmitch has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** ajmitch__ has quit IRC
*** dimas__ has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** dimas__ has quit IRC
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** derek has quit IRC
*** yure has quit IRC
*** kilo has left #gnuenterprise
*** jcater has quit IRC
*** klasstek has quit IRC
*** ajmitch__ has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** ajmitch has quit IRC
*** derek has joined #gnuenterprise
*** krizz_ has joined #gnuenterprise
*** krizz_ has quit IRC
*** krizz has quit IRC
