*** Administrator_ has joined #gnuenterprise
*** MangoMadness has quit IRC
*** titopbs has quit IRC
*** mnemoc has joined #gnuenterprise
*** mnemoc_ has quit IRC
*** reinhard has joined #gnuenterprise
*** apauley has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<kilo> good morning
<reinhard> good morning
*** btami has joined #gnuenterprise
<btami> good morning
*** photon_ has joined #gnuenterprise
*** StarDeep has quit IRC
* btami is away: i'm busy
<lekma> morning everyone
<StarDeep> hello
<reinhard> hi lekma
<lekma> how are you today??
<reinhard> fine, thanks
<reinhard> and you?
<reinhard> I see you use multithreaded clients?
<reinhard> you are *way* ahead of gnue-forms :)
<lekma> no i just tried
<lekma> it's worth exploring it a bit more
<lekma> :)
<lekma> are the errors i mentionned before surprising you?
<reinhard> in a way they are
<reinhard> you did not run *appserver* multithreaded, did you?
<lekma> nope
<lekma> that was just the client
<reinhard> looking at your second traceback
<reinhard> geasList.__getInstance has something like
<reinhard> record = self.__recordset.nextRecord ()
<reinhard> ...
<reinhard> self.__recordset.close ()
<reinhard> and the close gives the traceback
<reinhard> saying that __recordset is None
<reinhard> while the self.__recordset.nextRecord just before worked fine
<lekma> the errors are not for the same transaction
<reinhard> yeah, just looked at the second error for now
<reinhard> (didn't get the first traceback completely in the logs)
<lekma> well anyway for me that's to play with a bit later when golive is over...
<lekma> ...and that is not easy
<reinhard> how's golive going?
<lekma> well the data migration is a pain in the ass
<lekma> and we would need more time to polish integration test
<lekma> apart from that (and the fact that it is so slow) it's going well
<reinhard> it == data migration, the project, or the software?
<lekma> all of them
<reinhard> uh
<lekma> but the slowness is appserver-side
<reinhard> any specific hints?
<reinhard> what cases or what kinds of transactions are making it slow?
<lekma> that's why i tried to play a bit with threads tonight
<lekma> to try and pinpoint any specific situations
<reinhard> ah ok
<lekma> the worst ones are procedures
<lekma> especially if you call external python script
<lekma> if the script is doing more than 1 + 1
<lekma> :)
<lekma> it's slooooooooooooooooooooooooooow
<reinhard> hmmm... I guess especially the calling of external files is an inherent python problem
<reinhard> there is a way of compiling optimized modules in python
<lekma> and the xul 'engine' is all external python script called from a procedure
<reinhard> don't know how it works, but it somehow generates "pyo" files from "py" files
<reinhard> did you ever look at that?
<lekma> nope, but i'll do it
<lekma> pyo
<lekma> never heard of that
<reinhard> if you look at /usr/lib/python2.3, that dir is full of them
<lekma> yep, i'll have a look as soon as i can
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<johannesV> reinhard, is it safe to commit some new changes to appserver right now ?
<lekma> morning johannesV
<johannesV> hi lekma
<johannesV> wrt 'slow transactions'
<johannesV> do they have something to do with data-migration ?
<johannesV> i mean, are you going to modify quite large amount of records before commiting ?
<lekma> what do you mean (cause right now everything has to do with data migration)
<johannesV> lekma, do you have 'big' transactions (with lot's of records) or 'small' transactions ?
<lekma> depends
<lekma> for material we have one big
<lekma> per article
<lekma> then a few small
<lekma> for customer
<lekma> it'the other way around
<reinhard> johannesV: I think it's always safe to commit changes :)
<lekma> oh, btw, i never asked, but is there in gnye world any tool that could ease the process of putting data in appserver
<lekma> s/gnye/gnue
<johannesV> lekma, you mean aside from gnue-schema ?
<lekma> yep
<johannesV> there's 'gnue-integrator' but it's not implemented right now
<johannesV> lekma, regarding transactions: are both of them slow (big and small ones) ?
<lekma> yes
<lekma> one factor of slowness also
<lekma> is (even if it's obvious, i assure you you can feel it) overloading OnInit, OnValidation...
<lekma> bounded proc
<reinhard> you mean overloading as in "put too much code in it"
<lekma> we have a class that creates objects in other classes in oninit and on validation
<lekma> and performs
<lekma> a few checks based on find
<lekma> and you can nearly see the bytes flow... :)
<reinhard> oh, I can figure that
<johannesV> regarding commit: i did that sortfield-attribute 'ignorecase' yesterday in common and appserver
<reinhard> will that make appserver depend on new common?
<johannesV> does this interfere current release-process ?
<johannesV> no appserver can handle all forms of a sort-order-statement
<lekma> johannesV: how do i use it? :)
<johannesV> like ['foo'] or [('foo', True)] as well as [('foo', True, False)]
<reinhard> johannesV: then it's ok
<johannesV> or mixed all up
<johannesV> but the other way round could be a prob
<johannesV> like having new common and old appserver
<lekma> the third is ignorecase
<lekma> ?
<johannesV> lekma, right
<reinhard> johannesV: I would start to consider a dictionary for that
<johannesV> ignorecase defaults to False btw
<lekma> ???
<reinhard> instead of a tuple
<lekma> so if you want case insensitive it g=has to be true
<johannesV> lekma, right
<lekma> ok thx
<johannesV> lekma, but it's not commited yet
<lekma> oh ok
<reinhard> johannesV: you mean new common on client side and old appserver on server side?
<johannesV> reinhard, you mean something like {'name': 'foo', 'descending': False, 'ignorecase': True}
<johannesV> reinhard, yes for example
<reinhard> johannesV: exactly
<reinhard> who knows what will come next
<johannesV> reinhard, yeah, i've thought about this for about 5 seconds yesterday evening ..
<johannesV> (but for the sake of beeing faster keeping the tuple-system i threw it away)
<reinhard> ok
<johannesV> [faster in a sense of 'finished implementation']
<reinhard> let's say with the next parameter we introduce a dictionary :)
<johannesV> as i don't think passing sort-order is a matter of performance
<johannesV> hmm
<johannesV> now, as you've mentioned the same idea ... i think i'll change it today (if the kids are willing to sleep after lunch ... :)
<reinhard> no hurry
<johannesV> i think having a dictionary for 'new'-style and a tuple for 'old'-style we could make the combination of common and appserver quite tolerant
<johannesV> bbl
*** kilo has quit IRC
* btami is back (gone 01:20:38)
*** kilo has joined #gnuenterprise
*** StarDeep has quit IRC
<kilo> python 2.3.5 is out today
<ajmitch_> great, what changes?
<kilo> http://www.python.org/2.3.5/NEWS.html
<kilo> johannesV: Bug #1055820...
*** apauley has quit IRC
<johannesV> kilo, we're not using weakrefs ...
<kilo> but there was some issue like this iirc
<ajmitch_> fyi: http://gruppy.sicem.biz/componentes
<btami> gtk only, no appserver, no reports, etc.etc.
<btami> bbl
*** btami has quit IRC
*** tiredbones has joined #gnuenterprise
<tiredbones> Good morning all. Tommorrow we are going to get a foot a snow!
<tiredbones> cd /usr/lib/gnue
<ajmitch_> hi
<ajmitch_> I'd welcome snow at the moment
<ajmitch_> it's 2am & I'm sitting here with my windows open trying to keep cool
<tiredbones> where is here?
<kilo> LOTR-land
<ajmitch_> which is why it's thursday already :)
<kilo> 8-)))
*** titopbs has joined #gnuenterprise
*** kilo has quit IRC
<reinhard> tataaa
<reinhard> ajmitch_: more work for you approaching
* reinhard is releaseing gnue-appserver 0.4.0
<johannesV> kilo, we're not using weakrefs ..
<johannesV> sorry ... this was a cursor-up and enter typo ...
*** jamest has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** titopbs has quit IRC
*** johannesV has quit IRC
*** jcater_ has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** jcater has quit IRC
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** wendall911 has joined #gnuenterprise
*** SachaS has joined #gnuenterprise
*** titopbs has quit IRC
*** sjc has joined #gnuenterprise
<lekma> congrats on the release, see ya tomorrow
<lekma> bye
*** lekma has quit IRC
*** holycow has joined #gnuenterprise
*** sjc has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** johannesV_ has quit IRC
*** kilo has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** SachaS has quit IRC
*** derek has quit IRC
*** sjc has quit IRC
*** reinhard has quit IRC
*** mdean has quit IRC
*** reinhard has joined #gnuenterprise
*** mdean has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** titopbs has quit IRC
*** kilo has quit IRC
*** jcater has quit IRC
*** wendall_away has quit IRC
*** ajmitch_ has quit IRC
*** Flusher has quit IRC
*** Vee has quit IRC
*** Flusher has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** wendall_away has joined #gnuenterprise
*** ajmitch_ has joined #gnuenterprise
*** Vee has joined #gnuenterprise
<reinhard> night all
*** reinhard has quit IRC
*** titopbs has quit IRC
*** sjc has quit IRC
*** jamest has left #gnuenterprise
*** kilo has quit IRC
*** mnemoc_ has joined #gnuenterprise
*** mnemoc has quit IRC
*** jgw has joined #gnuenterprise
*** jgw has left #gnuenterprise
*** jgw has joined #gnuenterprise
*** jgw has quit IRC
*** jgw has joined #gnuenterprise
*** jgw has quit IRC
*** Administrator_ has quit IRC
*** titopbs has joined #gnuenterprise
*** jcater_ has joined #gnuenterprise
*** jcater has quit IRC
*** ajmitch has joined #gnuenterprise
*** ajmitch_ has quit IRC
*** holycow has quit IRC
*** wendall911 has quit IRC
*** jcater_ has quit IRC
*** mike1971 has joined #gnuenterprise
<mike1971> hello
<mike1971> Anyone online?
*** mike1971 has left #gnuenterprise