*** johannesV has joined #gnuenterprise
<johannesV> good morning people
*** btami has joined #gnuenterprise
<btami> morning
*** kilo has joined #gnuenterprise
<johannesV> hi btami
<johannesV> hi kilo
<kilo> hi johannesV
<kilo> good morning
<kilo> johannesV: there are filters in appserver world. it asks for the filter parameter on starting up - what? ie if you have several forms chained up in navigator, do you need to give this parameter each time you start a form? or is it only needed once?
<johannesV> wow, a good question
<johannesV> i would have to check, but usually the filter values are stored per appserver-session
<johannesV> so it would be needed just once
<kilo> do different forms launched from navigator count as one session?
<johannesV> ok, have checked it
<johannesV> yes it is only one session
<johannesV> they are all startet using the same connection-manager (and connection)
<kilo> ok, great. thx.
<johannesV> you would have to enter the filter-vals only once
<johannesV> but we have not defined how to 'change' such filters during lifetime of a session
<johannesV> (from outside)
<kilo> it should be a menu action imho
<johannesV> right
<johannesV> but we haven't defined how to connect/disconnect menus in navigator
<johannesV> like: you have started three forms (all with parameterset A) then you change the session-params and start another form; since all forms are using the same session this could make the first forms behave strange
<johannesV> if we change the start-mechanisms to use one session per step (form/report) we would have to re-enter login-data every time
<johannesV> (which is not what navigator is built for)
<kilo> ah, i see the problem
*** lxf has joined #gnuenterprise
*** lxf has quit IRC
*** lxf has joined #gnuenterprise
*** dimas has quit IRC
<kilo> johannesV: do you know something about iomporting triggers in forms?
*** btami has quit IRC
*** dimas has joined #gnuenterprise
<johannesV> kilo, haven't tried that, but i can imagine it's working ...
<kilo> hmm
<kilo> then i'll wait for the americans 8-))
<kilo> johannesV: what is Buss und Bettag?
<johannesV> this is next week (on 17th i think); it is a holiday in germany (at least)
<johannesV> dunno if it's a public holiday in austria too
<kilo> and what does it mean?
*** lxf has quit IRC
*** kilo has quit IRC
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** jamest has joined #gnuenterprise
*** lxf has joined #gnuenterprise
*** lxf has quit IRC
*** lekma has joined #gnuenterprise
<lekma> hi all
<lekma> is there anybody running appserver right now that can test generated forms on a 'big' (20 or more properties) class?
<lekma> please
<lekma> there is some kind of a 'memory leak' (not sure if it's the exact wording) when using generated forms...
<lekma> btw, is there any way to disable complete traceback on errors (i just need to know there was an error, the traceback is disturbing for users :-) )
<johannesV_> lekma, what kind of traceback ?
<lekma> all of them :-)
<johannesV_> lekma, which uidriver are you using ?
<lekma> xul (ie the one i'm building)
<lekma> and i rely on appserver traceback
<lekma> to get errors
<lekma> but it's awfully long and redondant sometimes
<lekma> so i was wondering if there was
<lekma> a way to deactivate the complete traceback
<lekma> and on ly get the error
<lekma> s/on ly/only
<lekma> johannesV_: that'not very important atm
<johannesV_> there is no such thing right now; anyway, appserver raises exceptions which get 'flattened' by the rpc-layer and rebuilt on the other side (client). appserver uses 'RemoteErrors' for doing this.
<johannesV_> so an arbitrary exception is encapsulated into an other one
<johannesV_> which get's 'unpacked' on the other side
<johannesV_> usually the uidrivers (at least gtk2) handles excpetions quite handy
<johannesV_> by displaying just a message (the error) and optionally displaying a 'detail'-button
<johannesV_> which shows the traceback (on request)
<johannesV_> so the point to get in would be where you catch the exception (on rpc-level)
<chillywilly> hi
<lekma> hum... then maybe i can copy this behaviour
<chillywilly> you guys talk a lot
<chillywilly> will you shutup already
<johannesV_> right, at least you can 're-build' the exception to a format more handy for xul
<johannesV_> hi chillywilly
<lekma> hi chillywilly
<johannesV_> lekma, what about the other prob with the 20 prop-class ?
<chillywilly> wassup?
<lekma> can you try using a generated form from gnue-appserver repeatedly and watch memory usage of gnue-appserver?
<lekma> it seems memory isn't freed when releasing a form
<lekma> it's more obvious with big forms
<lekma> that's why the 20 or more properties
<lekma> and i basically follow the generated forms trail to build my generated xul forms, so i face this exact problem now
<johannesV_> lekma, you have the latest svn, do you ?
<johannesV_> how can i best check appserver's memory usage ?
<lekma> nope i stopped at 0.3.1
<lekma> watching top
<johannesV_> so you're not using the new form-generator ?
<lekma> no
<lekma> is the new form generator post 0.3.2
<lekma> ?
<johannesV_> hmm, np, but i really did a nice rewrite of that part of appserver two weeks ago
<chillywilly> xul is very cool
<chillywilly> hey I rhyme
* chillywilly is a poet and didn't know it
<lekma> chillywilly: add it two more verses and you have a haiku
<lekma> :)
<lekma> johannesV_: so if i install 0.3.2 i'll have new form generator, right?
<johannesV_> right
<johannesV_> it creates tabular forms for small classes and has a better layout-management for larger classes
<lekma> i'll try and see if i can reproduce this memory behaviour with 0.3.2
<johannesV_> lekma, using top it seems that the appserver-process is eating memory ... :)
<lekma> :)
<lekma> and it gets ugly when you arrive at 90% memory eaten
<johannesV_> but i'm not sure if this is appserver- or python-related
<johannesV_> i'll try to dig into this at the weekend
<lekma> i tried to find out why
<lekma> and it seems common has
<lekma> references to objects that don'get collected by the garbage collector
*** agile has quit IRC
<lekma> it seems it's not appserver nor gform generation that is guilty
<lekma> but i'm no expert
<johannesV_> ok if i store the generated form using ?debug-file=...
<johannesV_> the memory-usage still grows but not that fast (it seems)
*** Vee2d2 has joined #gnuenterprise
* johannesV_ leaves for a cup of coffee and a piece of cake ...
<lekma> what i also tested was running 'pure' gnue-appserver transaction (request, open, call, ...) thousands of times, and i was quite surprised to see the memory not eaten
<lekma> but as soon as i asked lists of elements generated by a find in a python procedure, memory usage grows
*** agile has quit IRC
*** agile has joined #gnuenterprise
<johannesV_> ok, that's an interessting point
<johannesV_> on my system using 'generated' form consumes about twice as much memory as using 'stored' forms
<johannesV_> but i'll try to search in the find-direction ..
<johannesV_> lekma, do you have appserver on the same machine running as your forms- (xul-)client ?
<johannesV_> i mean, could it be the rpc-stuff causing troubles ...
<lekma> johannesV_: no i have a server for appserver and clients are not running on the same machine
<lekma> server is linux
<lekma> clients are win32
<johannesV_> hmm, yeah, ...
<johannesV_> bbl
*** dcmwai has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** feti has quit IRC
*** dneighbo has quit IRC
<lekma> bbl
*** lekma has quit IRC
*** feti has joined #gnuenterprise
*** dneighbo has joined #gnuenterprise
*** cilkay has quit IRC
*** dcmwai has quit IRC
*** johannesV_ has quit IRC
*** dneighbo has quit IRC
*** kilo has joined #gnuenterprise
*** kilo has quit IRC
*** kilo has joined #gnuenterprise
<kilo> jamest: do you know how import-trigger works?
<jamest> wow
<jamest> i haven't used it in ages
<jamest> you can put named triggers in a seperate file
<jamest> then import them to share them between forms
<kilo> dso you have any example? i've tried that and havent succeeded
<kilo> i have a trigger repeated in about 10 forms and i would like to move it to a separate file for reuse
<jamest> i dont
<jamest> but i thought there were samples in the user guide
<kilo> hmmm
<kilo> so i cut out the trigger from the form, and place it in, say, util.gfd. only the trigger code, nothing else.
<kilo> then i write   <import-trigger library='util.gfd' name='aaa'/> in the form in place of the trigger
<kilo> am i right?
<jamest> i think so
<jamest> i believe the name="" sets the name in the current form
<jamest> and there might be a src="" to select the trigger name in the library
<kilo> bad news then, it does not work this way
<kilo> jcater: do you have any info on this?
<jamest> :(
<jamest> kilo let me look in the logs
<jamest> <import-trigger library="file.gfl" name="TriggerNameToImport>
<jamest> from the 11/09/2004 log
<jamest> er
<jamest> 11/09/2002
<jamest> it's been a while since we did that :)
*** kilo has quit IRC
*** kilo_ has joined #gnuenterprise
*** dneighbo has joined #gnuenterprise
<kilo_> jamest: thx, though it was of no help, just the info we already knew
*** cilkay has joined #gnuenterprise
*** jamest has quit IRC
*** kilo_ has quit IRC
*** jbailey has quit IRC
*** cilkay has quit IRC
*** cilkay has joined #gnuenterprise
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** cilkay has quit IRC
*** sjc has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** sjc has quit IRC
*** dcmwai has joined #gnuenterprise
*** dcmwai has quit IRC