*** kilo has joined #gnuenterprise
*** kilo has left #gnuenterprise
*** reinhard has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<reinhard> bbl
*** dcmwai has quit IRC
*** sjc has quit IRC
*** reinhard has quit IRC
*** jamest has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> hello all
<lekma> reinhard: u around?
<reinhard> yes
<lekma> sorry i found out what i was looking for
<lekma> (pidfile option)
<lekma> the server is really faster
<lekma> i decided to put latest svn in prod
<reinhard> wee
<reinhard> so much faster? :)
<lekma> :)
<lekma> well starting
<lekma> is amazing
<reinhard> not only for start but also faster for usage?
<lekma> so now i can reload all repo
<lekma> without disturbing much the users
<lekma> for usage as weel
<lekma> s/weel/well
<lekma> but it's harder to see
<lekma> cause of the xul forms overhead
<reinhard> ok
<lekma> but request count fetch procs are faster
<reinhard> what i was thinking lately about your xul form stuff
<reinhard> you store some kind of form definition in the db, right?
<lekma> yep
<reinhard> if you request that form definition, do you always use the same session, or do you use the session of the client?
<lekma> client session
<reinhard> if all client would use the same session for retrieving the form definition, appserver could maybe cache much better
<lekma> hmmm
<lekma> i do believe you
<lekma> but i think the design i choosed is flawed anyway
<lekma> and slow by design
<lekma> i think we'll have to redo the all thing once this project is finish
<lekma> and maybe make it a gnue sub-project
<lekma> so that more people can think about it
<lekma> and if it fits their need
<lekma> they can maybe use it
<lekma> :)
<lekma> but i think there will be some licensing issue,no?
<lekma> cause xul/mozilla/and friends are mpl, and gnue is all gpl
<lekma> anyway these are just thoughts
<reinhard> don't know enough about xul anyway to say anything here :)
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** kilo has quit IRC
<lekma> back to the question, i could force the use of a session to use better cache?
<reinhard> yes
<lekma> now the client lauches a proc that import some external python and passes the session object
<reinhard> although I am not sure this will be possible in following versions of appserver
<reinhard> (for security reasons
<lekma> how would i pass the session (let's say) 0
<lekma> that's also came to my mind
<lekma> security
<reinhard> it might become impossible to use a "foreign" session id
<lekma> if the user has no right to see those forms
<lekma> and session highjacking will be over...
<lekma> (it comes handy atm for some testing where you don't want to go through the all open proc)
<lekma> reinhard: are there some incompatibility between statup option
<reinhard> yep, session hijacking is a big security risk
<lekma> ?
<lekma> ie -Z and pidfile or debug-file
<reinhard> there shouldn#t
<reinhard> shouldn't
<lekma> it seems if i use -Z and pidfile and debug-file
<lekma> i get the output
<reinhard> err
<reinhard> scratch that
<lekma> but nothing send to debug-file
<reinhard> -Z and --pidfile are exclusive
<lekma> and no pidfile
<lekma> ok
<reinhard> because they make no sense in combination
<lekma> well
<reinhard> you would only use a --pidfile if you don't run in foreground
<reinhard> wouldn't you?
<lekma> why ?
<lekma> i intend to use the pidfile
<lekma> to make a reload
<lekma> but still
<lekma> want to see debug output
<lekma> and send it to a file
<lekma> for others to look at
<reinhard> debug to file should work with --pidfile in any case
<lekma> what i should have in the file is the same as what on stdout
<lekma> ?
<reinhard> when you use --debugfile you don't get anything on stdout
<reinhard> you get it on debug file *instead*
<reinhard> wasn't that always so?
<lekma> ahhh
* reinhard has messed with debugging features lately
<lekma> so -Z and debug-file are exclusive also
<reinhard> no
<reinhard> you can run in foreground but still not want debug output on screen
<lekma> /usr/bin/gnue-appserver --web-frontend --loglevel 1 --debug-file /var/log/gnue/`date +%Y%m%d-%Hh%Mm%Ss`-geas.log -Z
<lekma> here is my start command line
<lekma> the logfile is created but nothing is sent to it and i still have screen output
<mnemoc> what --web-frontend is?
<lekma> i starts a web server
<lekma> it starts a web server
<lekma> i use it to store pictures
<lekma> and render them in a navigator widget in xul
<mnemoc> :)
<lekma> comes in handy
<lekma> :)
<mnemoc> nice
<lekma> DB000: Traceback (most recent call last):
<lekma> DB000:    File "/usr/bin/gnue-appserver", line 33, in ?
<lekma> DB000:     server = geasRpcServer.geasRpcServerApp ();
<lekma> DB000:    File "/usr/lib/gnue/appserver/geasRpcServer.py", line 113, in __init__
<lekma> DB000:     geasConfiguration.ConfigOptions)
<lekma> DB000:    File "/usr/lib/gnue/common/apps/GServerApp.py", line 71, in __init__
<lekma> DB000:     self.__createPidFile (0)
<lekma> DB000:    File "/usr/lib/gnue/common/apps/GServerApp.py", line 184, in __createPidFile
<lekma> DB000:     pidfile = open (self.OPTIONS ['pidfile'], 'w')
<lekma> DB000:  IOError: [Errno 2] No such file or directory: '/var/run/gnue/appserver.pid'
<lekma> when started with /usr/bin/gnue-appserver --web-frontend --loglevel 1 --debug-file /var/log/gnue/`date +%Y%m%d-%Hh%Mm%Ss`-geas.log
<lekma> no pidfile option
<reinhard> --pidfile just changes the localtion
<reinhard> no --pidfile option doesn't mean it doesn't write a pid file, it just means it writes to standard location
<lekma> and when started with pidfile option, nothing is sent to debug-file
<lekma> hmmm
<reinhard> and to get debug output you need to specify a --debug-level
<reinhard> well
<lekma> ahhh
<reinhard> maybe the misunderstanding is
<lekma> sorry
<lekma> i use loglevel
<lekma> and i thougt it was ok
<reinhard> the messages that are printed on appserver startup like "Appserver up and running" do not count as debug output
<reinhard> neither are (IIRC) the loglevel messages from xmlrpc
<reinhard> they both go to stdout
<reinhard> (IIRC)
<reinhard> try > stdout 2> stderr
<reinhard> and see where the messages end up :)
<lekma> ok will try
<reinhard> but I would *bet* stdout because actually with --debug-file we catch stderr and redirect it to the debug file
<reinhard> did this work before? did I break something?
<reinhard> like I said, I messed a bit with those debug options
<lekma> i don't if it worked before
<lekma> i don't know if it worked before
<lekma> i'm just messing trying to find the best option
<lekma> to have the pid in a file
<lekma> and some kind of a log file
<lekma> not to verbose
<lekma> and not too terse
<reinhard> lekma: --debug-level=1-4 should be what you are looking for
<lekma> thx
<reinhard> DB001: would be all warnings
<reinhard> DB002: are info about system configuration
<reinhard> DB003: is the SQL code sent to the database backend (helpful for finding performance killers)
<reinhard> DB004: is calls to the appserver API with parameters and return values
<lekma> DB004 is really verbose, DB003 not enough... :(
<lekma> i'm never happy
<lekma> :)
<reinhard> bbl
*** jcater has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
<lekma> reinhard: if you read this, on my server the debug-file is not written in "real time"
<lekma> ie i have to stop the server to have the debug infos actually written in the disk
<lekma> is this normal behaviour??
<jcater> I've hit this with some of my non-gnue python apps
<jcater> the solution is to do a
<jcater> filehandle.flush()
<jcater> right after the filehandle.write() call
<jcater> (in GDebug.py, I assume)
<lekma> thx jcater
*** wendall911 has joined #gnuenterprise
<lekma> for those of you who need debug-file written to disk immediately:
<lekma> --- GDebug.py   2005-03-18 17:44:23.015478904 +0100
<lekma> +++ GDebug.py.new       2005-03-18 17:32:43.000000000 +0100
<lekma> @@ -73,6 +73,7 @@
<lekma>        del (lines [-1])
<lekma>      self.filehandle.write (string.join (["DB000: " + s for s in lines], "\n"))
<lekma>      self.filehandle.write ("\n")
<lekma> +    self.filehandle.flush ()
<lekma>    def writelines (self, list):
<lekma>      for line in list:
<lekma> @@ -155,6 +156,7 @@
<lekma>    lines = "%s" % message
<lekma>    for line in lines.splitlines ():
<lekma>      _fh.write ("DB%03d: %s %s%s%s" % (level, stamp, filename, line, os.linesep))
<lekma> +    _fh.flush ()
<lekma>    if dropToDebugger and _DEBUGGER:
<lekma>      _DEBUGGER.set_trace ()
<lekma> apply to gnue.common.appsGDebug.py
<lekma> apply to gnue.common.apps.GDebug.py
*** btami has joined #gnuenterprise
<jcater> lekma: I applied the patch permanently to svn
<lekma> jcater: ok
* btami is away: 
<reinhard> jcater: thanks, wanted to propose the same
* btami is away: 
*** dcmwai has joined #gnuenterprise
<btami> jcater: in the online svn there is no color in diffs
<btami> maybe you can fix it...
*** dcmwai_ has joined #gnuenterprise
*** dcmwai has quit IRC
*** dcmwai_ has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> hi
<johannesV> lekma, as i can read from the logs you're quite happy with my latest improvements in appserver .... :)
<lekma> yep
<johannesV> so that's good news
<johannesV> i'd like to add some 'benchmark' stuff (gcd and li-scripts) first and then add the dependency-stuff for inserts and deletes
<lekma> johannesV: i'm trying to compare perf from between generated gnue-forms and xul forms
<johannesV> as well as make appserver use of all that new things in common's dbdriver (like directly inserting or updating)
<lekma> and i can't launch any gnue generated forms atm
<johannesV> as i saw in reinhards commit mails he did a change in callFunc, so are you using latest svn ?
* johannesV is trying a generated form ...
<johannesV> works fine for me
<lekma> in gnue.common.datasources.GDataSoure.py line 939 it says:
<lekma> parts = appUrl.split ('/')
<lekma> shouldn't it be:
<lekma> parts = url.split ('/')
<johannesV> why ?
<johannesV> first we strip away that 'appserver://'
<lekma> if i understand correctly appUrl is only "appserver://"
<johannesV> then, if there are options behind a '?' we don't need them too
<johannesV> so url get's translated into appUrl
<johannesV> having only the part in between split into the three parts: server, resource-type and resource-name
<lekma> gnue-forms "appserver://gecocer/basics_langs"
<lekma> is correct?
<johannesV> no
<lekma> oh
<johannesV> gnue-forms appserver://connectionname/resourcetype/resourcename
<johannesV> where connectionname is the name of the appserver-connection in your connections.conf
<johannesV> resource-type is 'form' atm, but is thought to also support report in a time
<johannesV> and resource-name is the name of the class (atm)
<johannesV> and, well, appserver:// gives forms the hint to use an appserver-resource
<johannesV> that's all about :)
<lekma> ok it works
<johannesV> fine
<johannesV> i'm glad i could help you
<lekma> i forgot the resourcetype
<johannesV> right
<lekma> the form generation seems faster than it used to beas well
<lekma> the form generation seems faster than it used to be as well
<johannesV> hmm, might be
<johannesV> as i've optimized the caching a bit
<johannesV> but i think another boost will come with the next two major changes, first there's the use of the connection-functions insert/update/delete
<johannesV> instead of building a resultset for each
<johannesV> and the next (even bigger thing) will be the rewrite of the data.cache class and it's algorithm
<lekma> johannesV: the old classrep stuff is replaced by repository.py
<lekma> ?
<johannesV> (but the latter will be a hard nut to crack)
<johannesV> lekma, yes ... impressive, isn't it :)
<lekma> yep
<johannesV> (as i've written the former too)
<johannesV> but, the big difference is, that the old repository was built upon the language interface completely
<johannesV> and the new one is using data.py and a better wrapping mechanism around the language interface
<lekma> can i use the updateLinks functions to "reload" a class or a procedure
<lekma> ?
<johannesV> no, updateLinks has one major purpose: replace gnue_id's by the apropriate wrapper-instance or (in unlink-mode) clear all references to let garbage collection work fine
<johannesV> it does not fetch any new data from the backend nor does it merge some data with the existing instances
<johannesV> the only way to update classes in the repository is a call of repository.load () [or sending SIGHUP to appserver process]
<johannesV> to be precise, you've to watch out if you're calling repository.load () directly: make sure to have your session's cache beeing cleared, otherwise you won't get new data from the backend
<johannesV> you could achieve this by calling a session.rollback () [usually the repository is using the internal session]
<johannesV> lekma, do you still need to reload single classes ?
<lekma> single procs would be perfect
<johannesV> why ?
<lekma> lots of concurrent changes
<lekma> on procs
<johannesV> you change the procedures' code that frequently ?
<lekma> well....
<lekma> ...yes :)
<lekma> i'm not the only one working
<lekma> on the server
<lekma> and a lot of "functionnal" proc (order creation, bill of material)
<lekma> are undergoing some changes
<lekma> since 2 or 3 days
<lekma> (that's the go live effect)
<johannesV> :)
<johannesV> hmm
<lekma> even if it's only for a short time and reserved to devs only
<johannesV> so sighup's not an option
<lekma> reloading procs would be useful
<johannesV> well, the problem would be all that cross-references in the repository ...
<lekma> i didn't have the time to implement it again
<johannesV> would it be sufficient to have the proceudre's code reloaded
<lekma> i can still try with the sighup
<johannesV> or do you change the signature as well ?
<lekma> signature??
<johannesV> i mean, the parameters, result-type ...
<lekma> nope for this we run gnue-readgcd
<johannesV> how do you change the procedure-code ?
<johannesV> using a special form ?
<lekma> yep in a form
<lekma> textarea
<johannesV> to have a procedure's code beeing reloaded it would be sufficient to remove the attribute 'gnue_code' from the instances __dict__
<johannesV> if x is a procedure-element in the repository, you could do: del x.__dict__ ['gnue_code']
<johannesV> the next access to x.gnue_code should force the language interface to reload the code from the backend
<johannesV> brb
*** sjc has joined #gnuenterprise
<johannesV> ok
<johannesV> back
<johannesV> let me try something ...
<johannesV> ok, i have a 'hackery' solution for your pb
<johannesV> i think you have that additional rpc-function for reloading a single class, right ?
<lekma> yep
<johannesV>   def reloadProcedure (self, classname, procname):
<johannesV>     """
<johannesV>     """
<johannesV>     p = self.repository.classes [classname].procedures [procname]
<johannesV>     if p.__dict__.has_key ('gnue_code'):
<johannesV>       del p.__dict__ ['gnue_code']
<johannesV>     self._internalSession.rollback ()
<johannesV>     newCode = p.gnue_code
<johannesV> this should do the job
<johannesV> you might change that rpc-function to take another parameter (the name of the procedure) and add this python-code to geasSessionManager.py
<lekma> thx
<johannesV> note, the last line (newCode = p.gnue_code) is kind of optional
<johannesV> if you omitt it, the code will be fetched from the backend, the next time the procedure would be executed
<johannesV> so if you keep that line, the code will be loaded imediately
<johannesV> if classname does not exist in the repository, a ClassNotFoundError will be raised
<johannesV> if procname is not available, a ProcedureNotFoundError will be raised
<johannesV> brb
<lekma> are classname and procname full names (ie module_class and module_proc)?
<lekma> or can i use gnue_ids?
<johannesV> for classname gnue_id is ok
<johannesV> for proc it's ok too
<lekma> thx
<johannesV> names must be qualified
<lekma> on perf side: i tried a generated form on a class with ~20 properties and one calc prop
<lekma> there is around 10000 records
<lekma> in table
<lekma> if i search without anything the first record is quite fast to be displayed
<lekma> but then if i hit last record
<lekma> the memory usage
<lekma> grows alarmingly
<lekma> and it takes ages to come (the last record)
<johannesV> hmm , calc. in cond or order?
<lekma> the mem usage starts from 1.3 % and stops at 8.4%
<lekma> nocond at all
<lekma> no cond at all
<lekma> i don't know about order in generated gnue-forms
<johannesV> order is given by search-fields
<reinhard> lekma: if you hit "last record" in forms
<lekma> no gld for this class
<reinhard> forms fetches through all records of the resultset
<johannesV> ok, i need to run now, but i'll read the logs
<johannesV> bye
<reinhard> bye
<lekma> bye
*** johannesV has quit IRC
<reinhard> lekma: would be interesting which side eats more memory: forms or appserver
<lekma> that server memory i'm talking about
<reinhard> ah ok
<lekma> shouldn't the last record button only fetch the last record?
<reinhard> for databases, there's usually no way of fetching the last record from a query
<reinhard> AFAICT
<lekma> but for appserver there is
<lekma> ??
<lekma> you can count
<lekma> and get the last
<reinhard> yes there is
<lekma> that's what i do in xul
<reinhard> but appserver has to get the data from the db somehow
<reinhard> so appserver has no other chance to fetch all records in between from the db too to get the data of th last record
<lekma> hmmm
<reinhard> and as it's already fetching through the list, it also caches the data
<lekma> what also interesting: without closing the session i came back to first record
<lekma> then hit next record a few times
<lekma> the first
<lekma> everything is fast
<lekma> and then last record again
<lekma> same behaviour
<lekma> but memeory
<lekma> grows only from 8.4% to 9.7%
<lekma> i think that part of this mem is freed anyway
<lekma> but not reclaimed
<lekma> by os
<reinhard> hmm
<reinhard> actually once you've hit "last record"
<reinhard> memory usage should be more or less constant
<reinhard> because all your records are in cache anyway
<reinhard> except for the other data that are fetched from the db to do calculated fields
<lekma> hmm i did hit rollback in the middle
<lekma> my bad
<lekma> if there is no rollback the mem usage is constant
<reinhard> ah
<reinhard> that's a good sign at least
<reinhard> although I would not bet my life on the fact that there are no memory leaks left ;-)
<lekma> :)
*** btami has quit IRC
*** popcorn has quit IRC
<chillywilly> derek: yo
<chillywilly> derek: were you into delphi development at one point?
*** kilo has joined #gnuenterprise
*** titopbs has quit IRC
<jcater> btami: viewcvs should be colorized now
<kilo> jcater: great thx
<reinhard> chillywilly: i have developed with delphi a long time ago
*** jcater has quit IRC
<lekma> night all
*** lekma has quit IRC
<nickr> I have to do things in delphi that make me weep in the night
<wendall911> nickr: windows dll?
<wendall911> nickr: actually that might cause suicidal tendencies
<nickr> No, I've written DLLs in C though
<nickr> that load and wrap other DLLs
<nickr> muahh
<wendall911> nickr: it's pretty much the same pain in Delphi
<nickr> I don't find it that painful
<nickr> except having to cast function pointers and whatnot
<wendall911> nickr: well, depends on if you need to interact with the M$ api
<nickr> Ah
<nickr> No, this is a totally different level
<nickr> very little winlib
<nickr> no gui either
<wendall911> I hadn't ever even really used windows and I had to write some dlls in c and delphi a few years back...my god what a shock
<wendall911> broken was an understatement
<nickr> I don't find it particularly broken
<wendall911> I ended up having to trace threads to figure out everything...functions are scattered everywhere
<wendall911> nickr: this was with windows 95/98 though
<wendall911> nt may be better, dunno
*** jamest has left #gnuenterprise
<mnemoc> hi, to do gnue-forms -u gtk2  do i need something else than pygtk?
<mnemoc> i still get: gnue-forms: Unknown UI driver specified: gtk2    :(
<mnemoc> and TypeError: __init__() got an unexpected keyword argument 'moduleName'     with -u curses :'(
*** kilo has quit IRC
<reinhard> mnemoc: oops, I get the same error for curses
<reinhard> but gtk2 works for me
<reinhard> mnemoc: fixed curses, if you use svn please update and try again
<reinhard> night all
*** reinhard has quit IRC
*** nictuku has joined #gnuenterprise
<nictuku> hi
*** sjc has quit IRC
<mnemoc> what do i need aditional to pygtk (2.6.0) to get gnue-forms -u gtk2 working? :(
*** nictuku has quit IRC
*** wendall911 has quit IRC
*** dcmwai has joined #gnuenterprise
*** wendall911 has joined #gnuenterprise
*** wendall911 has left #gnuenterprise
<mnemoc> building wxwidgets has been hour and a half eating my box :(
<mnemoc> i really wanted to use gtk2 ui :'(
*** dere1 has joined #gnuenterprise