*** ajmitch_ has joined #gnuenterprise
<lekma> good morning everyone
*** ajmitch has quit IRC
*** ajmitch_ is now known as ajmitch
*** reinhard has joined #gnuenterprise
<reinhard> good morning all
<ajmitch> good evening
*** yure has quit IRC
*** btami has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<btami> good morning
<johannesV> good morning
*** kilo has joined #gnuenterprise
<kilo> good morning
<johannesV> hm, looks like the python-bindings for kinterbasdb is still not fixed for breezy ..
<kilo> they are not :(
<kilo> maybe next release...
<johannesV> which packages were needed in order to compile that kinterbasdb ?
<johannesV> it was something with devel .. i think
<johannesV> ah, i think it was python-dev
<lekma> reinhard: i have a small bug which seems to have been induced by yesterday's changes
<lekma> if i _destroy a session
<lekma> and then close the tcp connection i get:
<johannesV> damn, i can't get it compiled ... kilo could you give me some advice
<johannesV> ?
<kilo> phone
<lekma> DB000: Exception in thread Thread-20:
<lekma> DB000: Traceback (most recent call last):
<lekma> DB000:   File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
<lekma> DB000:     self.run()
<lekma> DB000:   File "/usr/lib/python2.4/threading.py", line 422, in run
<lekma> DB000:     self.__target(*self.__args, **self.__kwargs)
<lekma> DB000:   File "/usr/lib/python2.4/SocketServer.py", line 467, in process_request_thread
<lekma> DB000:     self.close_request(request)
<lekma> DB000:   File "/usr/lib/gnue/python/gnue/common/rpc/drivers/xmlrpc/ServerAdapter.py", line 378, in close_request
<lekma> DB000:     self.serverAdapter._clearClientObjects (request.getpeername ())
<lekma> DB000:   File "/usr/lib/gnue/python/gnue/common/rpc/drivers/xmlrpc/ServerAdapter.py", line 210, in _clearClientObjectsDB000:     self._destroy (item)
<lekma> DB000:   File "/usr/lib/gnue/python/gnue/common/rpc/drivers/xmlrpc/ServerAdapter.py", line 152, in _destroy
<lekma> DB000:     item._destroy ()
<lekma> DB000:   File "/usr/lib/gnue/python/gnue/appserver/geasSession.py", line 270, in _destroy
<lekma> DB000:     self.__connection.close ()
<lekma> DB000: AttributeError: 'NoneType' object has no attribute 'close'
<johannesV> lekma, please svn up ...
<lekma> ok
<reinhard> johannesV: I think a different fix would be better:
<reinhard> the problem seems to be that _destroy is called twice, isn't it?
<johannesV> right, i might get called twice
<reinhard> lekma: how did you call _destroy of the session?
<johannesV> and within _destroy () the __connection is unset
<johannesV> so the second call runs into troubles
<kilo> johannesV: you need firebird2-dev, python2.4-dev for sure
<kilo> and something more... but cant remember
<lekma> _call(sessobj, "_destroy")
<kilo> and btami has checked it, it is only available in dapper
<lekma> is that correct?
<reinhard> AFAICT you should do _destroy(sessobj)
<reinhard> because that would not only do the _destroy of the geasSession
<reinhard> but also remove it from the list of active objects in the server
<lekma> ok let me try
<reinhard> and the server would later know that it does not have to be _destroy'ed again
<johannesV> kilo, i've installed that python2.4-dev as well as all firebird2-*
<johannesV> but it still complains about a lot of syntax errors when calling python setup.py build
<kilo> i'm gonna try to make up what is needed still
<lekma> reinhard: well it works with johannesV fix
<lekma> but i will correct my calls anyway
<reinhard> lekma: I would still be interested if fixing the call fixes it without johannes' fix
<lekma> what would be the svn command to go back one update?
<reinhard> svn -r PREV up
<reinhard> IIRC
<lekma> hmm it says Skipped '.'
<kilo> johannesV: check irc logs for 2005-06-07 and 06-08
<reinhard> was it svn up -r PREV ?
<johannesV> hm
<johannesV> well i did all that steps but it still fails ...
<johannesV> which package contains stdio.h ?
<kilo> got it, you need the package build-essentials
<johannesV> downloading ...
<johannesV> kinterbasdb is installed (3, 2, 0, 'alpha', 1)
<johannesV> thanks for your help
<johannesV> i'll add some comments into our driver-file
<kilo> \o/
<kilo> all i had in my mind was 'it was a package starting with b...'
<reinhard> lekma: yes
<reinhard> svn up -r PREV
<lekma> yep
<lekma> correcting the calls fixed the pb
<reinhard> and does it still work with fixed _destroy calls?
<reinhard> excellent
<reinhard> johannesV: I would seriously recommend undoing this last change in geasSession then
<johannesV> i think it would be defensive to let the if-condition in there
<reinhard> yes and no
<johannesV> reinhard, why ?
<reinhard> calling _destroy twice is a bug
<johannesV> hm
<reinhard> and letting bugs undiscovered is not always a good thing
<reinhard> best example: if you let this in, lekma would never have discovered that he calls _destroy the wrong way
<johannesV> yeah, ok
<johannesV> kilo, the bug you've reported on 02-16 is reproducable ...
<johannesV> but i'm not sure if it's a interbase-related one ...
<kilo> i am quite sure it is not
<johannesV> i've just found out how to avoid it
<kilo> i remember it was discussed eariler but wasnt solved
<johannesV> before iterating down all that records, jumpt to the last and back to the first
<johannesV> then it works fine
<kilo> erm... should i tell it to the customer? :)
<johannesV> but as soon as you've iterated over all records which had been fetched at first
<johannesV> an exception will be raised
<johannesV> no, you won't tell that your customer ... we're going to fix it now, shouldn't we ?
<johannesV> :)
<johannesV> but i've got some similar issue in mind with sqlite3
* johannesV needs some coffee first
* kilo smiles some ev0l way...
<johannesV> ok, it does work with postgres ... (not surprisingly)
<johannesV> hm, well
<johannesV> i can't reproduce it with any other db here ...
<johannesV> (other than firebird)
<kilo> maybe some firebird driver cursor issue then?
<johannesV> hard to say ... my pb is that it works if you first jump to the last record
<johannesV> and that calls the same functions as iterating through the records
<kilo> it is connected somehow with cursor size
<kilo> in zipcodes example it is set at 15 or so
<kilo> explicitly i mean
<kilo> in 'normal' cases, this all happens after record #5
<johannesV> no, it happens for 15 in my states.gfd
<johannesV> maybe it's a master-detail thingy
<johannesV> oh, wow
<johannesV> now i get it on a different position (after i've removed the cache="" attribute)
<johannesV> right, it happens after all chached records are scrolled through ...
<johannesV> but only on states.gfd ... if i apply the same to zipcode.gfd (without master/detail) it works fine
<kilo> hmmm so cache size plus M/D
<johannesV> maybe the pb is, that we have multiple open cursors at the same time there ...
<kilo> hmm can be
<kilo> and with one of them saving, ie committing, is that closed?
<johannesV> no need to change anything
<johannesV> the error appears just by iterating over the cache-size
*** yure has joined #gnuenterprise
<kilo> ah
<kilo> i thought it was commit-related
<johannesV> no, it isn't ... there's something wired with the firebird-cursors
<kilo> uh oh
<johannesV> ah, got it workin
<johannesV> just remove that autocommit="Y"
<kilo> see? it is commit related...
<johannesV> right, sorry :)
<johannesV> i haven't seen that there was an autocommit set
<sacha> night
*** sacha is now known as SachaZzzz
<johannesV> kilo, looks like a commit renders all open cursors invalid
<johannesV> yep
<johannesV> got it in a python-sample
<kilo> well, on one hand, ouch, on the other hand, can be understandable
<johannesV> hm, well, that seems to do the trick .. i've created a simple python-script opening a connection, creating a cursor, running an executed followed by two calls of fetchmany. this runs fine. if i add a commit between the fetchmany-calls the exception arises
<johannesV> a short check with sqlite3 shows, that sqlite's cursors aren't affected by an intermediate commit
<johannesV> same seems to apply to postgres
<johannesV> (could check it with maxDb too)
<johannesV> anyway, we'd have to think about a workaround for this situation
<johannesV> will talk to reinhard as soon as he's back ...
<kilo> hmm i can totally accept by now it closes the cursor... the commit can change the given record in a way that it should not be included in the cursor anymore, so keeping it open would be a mistake indeed
<kilo> it should be reopened instead
<johannesV> i think there's already such a concept (requery or the like) .... but reinhard knows that for sure :)
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** dimas has joined #gnuenterprise
*** btami has quit IRC
<lekma> wow
<reinhard> lol
<reinhard> went to customer, came back now, and saw that I was in the middle of a mail writing...
<lekma> someone has a little bit of time to lose?
<reinhard> lekma: sorry, not right now, I have that right behind me
<lekma> :)
<reinhard> spent 2 hours at a customer searching for a network problem and still don't know what's wrong
<reinhard> and had to go without fixing it, which is a considerable disappointment for me :(
<lekma> can i have the time at the millisecond precision with python?
<kilo> lol i did the same and concluded: call the one who set it up, he surely knows how to fix it
<kilo> (though i am pretty sure he does not...)
<reinhard> kilo: you mean looking for a network problem?
<reinhard> problem is they don't want to talk anymore to the one who set it up because they found out he is incompetent
<reinhard> (which says a lot about *how* the current status of the host in question is)
<kilo> so damn usual :(
<kilo> this one was like: first there was one big ms workgroup, shared printers, etc
<kilo> then he invented he separates every room into a new workgroup...
<kilo> but the fact it breaks printer shares... he just didnt care
<kilo> and what does poor customer say? 'the software doesnt print'
<reinhard> sure
<reinhard> and of course it's the fault of the software
<reinhard> especially if you were unlucky enough to just have installed an update a few days ago
<kilo> :) welcome to the club :)
<johannesV> lekma, on which os do you take the precise time ?
<johannesV> usually you could use time.time ()
<lekma> i just wanted to compare apples and oranges and was looking to have the time in millisecond with python on linux
<johannesV> but on msw it is only microseconds
<johannesV> (as the clock doesn't give a better resolution there)
<lekma> i benchmarked all javascript rpc impl i have
<johannesV> ah, ok, for benchmarks there's something different i think
<lekma> and was quite surprised by the results
<lekma> so i wanted to have a pure python base to see if i was not out of my mind
<johannesV> you could use either hotshot module or the profile (or pstats) module
<johannesV> using these modules you could see which function takes how much time ...
<johannesV> and much more
<lekma> not smthing that powerfull :), i just and overall execution time to have an idea (i failed to make the javascript profiler work, so i'm really in the subjective here)
<lekma> what do you make of that: 0:00:02.133180
<lekma> it's the result
<lekma> of datetime.datetime.now() - the same before
<lekma> is it 2 seconds and smthing
<kilo> indeed
<lekma> ok
<lekma> well one test to go and i'm off to bed...
<johannesV> :)
<lekma> bye
*** lekma has left #gnuenterprise
*** jamest has joined #gnuenterprise
<johannesV> hm, that usercommand-thing added to the keymapper causes some troubles ...
<johannesV> on a mac you enter the @- or €-symbol using Alt+L or Alt+E
<johannesV> so the keymapper converts such a keypress into a usercommand, instead of passing it through to the gfentry
<johannesV> jamest, can you tell me something about the intention of the 'usercommand' ?
<jamest> sure
<jamest> is that something I added recently?
<jamest> if so I believe it was to allow you to define a trigger to fire on a user defined key sequence
<johannesV> well, not recently ... but about one or two months ago
<jamest> sigh, that's recently for me unfortunately
<johannesV> ah, ok, i see ... :)
<jamest>  /msg johannesV and you think reinhard is a slave driver
<jamest> er....um..... :)
<johannesV> ok, and how is that 'trigger-command' defined ?
<johannesV> ah, ok i've found it ... on such a command the trigger named "KEY-<a-pressed-key-seq>" is fired
<jamest> yes
<johannesV> hm, ok, now i see ...
<jamest> however i was having issues passing back ctrl sequences iirc
<jamest> as they map differently, i think i was going to do something in the keymapper to fix this
<johannesV> hm
<johannesV> what kind of trigger is that you'd like to fire ?
<jamest> i added this for someone in IRC
<jamest> though I could see value in having custom keystrokes pop up dialogs and such to ease input
<johannesV> yes, i like the idea too, but i'd love to see it more formalized. so the keymapper would know such events not just pass everything which is not know to such an event
<johannesV> but maybe we could combine this with the general option of "user-defined" menu items
<jamest> yes
<jamest> i thought it would be nice to map those custom triggers to menu/toolbar items
<johannesV> so one could add a trigger code which is activated via menu (and having a keyboard-shortcut)
<johannesV> maybe we could add some attributes to the trigger-tag, like <trigger name="foo" key="Ctrl-G" description="Some fancy menu entry">....
<johannesV> or better menu="Some fancy menu entry"> ..
<johannesV> and all that triggers are then bound to a menu called "Extras" or the like
*** jcater has left #gnuenterprise
<johannesV> or maybe we could have menus and submenus
<jamest> there has been a few attempts at a user defined menu
<johannesV> like <trigger name="foo" key="Ctrl-G" menu="Exec foo" parentMenu="Foo-Extras">
<jamest> pulling the menu code from designer and moving to common
<jamest> but i don't recall where any of that stuff is at
<johannesV> i don't know the menu code from designer ...
<jamest> as far as progress
<jamest> iirc, it's dynamic so you can adjust menus on the fly
<jamest> and I think there might have been a start of a <menu> gfd structure at one time
<johannesV> yeah, that would be much cleaner anyway
<jamest> so you could create/override custom forms menus
<johannesV> having a <menu> hierarchy
<johannesV> would be great
<johannesV> i could imagine this could be a quite clean and very flexible solution
<johannesV> and i don't think it's very hard to accomplish anyway
<jamest> i think the hardest parts were going to be
<jamest> 1) how it interacted with the build in menu
<jamest>   could they override existing entries (handy)
<jamest> 2) making it so triggers could enable/disable/add/remove menu entries
<jamest> i know i have several forms where i hide the toolbar/menu and put a "complete" button on the form
<jamest> as I can't stop the F6 commit action and that doesn't do what I need on forms where all the blocks hook to unbound datasources
<johannesV> hm, right, that sounds reasonable
<johannesV> ok, so one pb would be to identify the standard (builtin) menus and their items
<johannesV> and another one to enable/disable or to hide them
<johannesV> from within a gfd-tree as well as trigger-code
<reinhard> must run, off until thursday
<reinhard> cu
*** reinhard has quit IRC
<jamest> i would think so
*** kilo has left #gnuenterprise
*** derek has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** yure has quit IRC
*** klasstek has joined #gnuenterprise
*** jcater has quit IRC
*** yure has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** btami has quit IRC
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV_ has quit IRC
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jamest has quit IRC
*** derek has quit IRC
*** klasstek has quit IRC
*** sjc has quit IRC
*** yure has quit IRC
*** jamest has joined #gnuenterprise
*** gaupe has quit IRC
*** ajmitch has quit IRC
*** nickr has quit IRC
*** chillywilly has quit IRC
*** ajmitch has joined #gnuenterprise
*** gaupe has joined #gnuenterprise
*** nickr has joined #gnuenterprise
*** chillywilly has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jason__ has joined #gnuenterprise
*** SachaZzzz has quit IRC
*** jason__ has quit IRC