*** jcater_ has joined #gnuenterprise *** jcater_ has joined #gnuenterprise *** jcater_ has quit IRC *** jcater_ has joined #gnuenterprise *** sjc has joined #gnuenterprise *** btami has joined #gnuenterprise good morning morning btami *** siesel has quit IRC *** kilo has joined #gnuenterprise good morning good morning *** reinhard has joined #gnuenterprise good morning still downloading 423 new mails hmmm, let me guess... viagra, penis enlargement, 323 million usd from zambia... reinhard: how was fosdem ? stressy http://www.fsfe.org we did an inofficial prelaunch yesterday at fosdem, official launch will be today and we had *tons* of last minute issues to solve so we sat in some hacker's rooms for *hours* and tried to fix things FWIW the backend database for this fellowship runs with gnue met SachaS and talked a little *** johannesV has joined #gnuenterprise good morning hi johannesV hi johannesV! hello reinhard, hi ajmitch reinhard, as i had a bit time this night ... i've thought about classrep if we would *not* use the language-interface for loading the repository then 'repository.ini' is obsolete and gnue.gsd could be a gnue.gcd and appserver could install himself (if the db-backend exists) on startup of course :) and it should be much faster hi johannesV IIRC we have already talked about not basing classrep on language interface any more that we wouldn't need a repository.ini any more and need no gnue.gsd either is surprising at first sight right, so the repository could even be disconnected from the session manager well, if we give a connctions instance and a database to the repository it can fetch everything from the backend (using data.connection) but as I still have some things to clean up and some mails to process I think I trust you enough to think right before you say such a thing ;-) build up the needed dicts and return a single dictionary: ModuleDict which will be used by the sessionManager this would also solve the problem of a sighup taking a bit longer to load ... sounds very good to me and since the repository can fetch everything from the backend directly we don't need to simulate already existing gnue_* classes (which were needed by the language interface only) yes, I think I understand cause the lang.intf. uses find () which uses __getClassdef in turn yes, right, that was our chicken egg problem exactly which goes away now right boiled eggs the question is now, what to put into such a ModuleDictionary, ClassDict ... for example if you access a non-existing key should we keep a logic in there to 're-fetch' it from backend I'd say no the sighup stuff replaces that IMHO of course so we could use 'normal' dictionaries here normal dictionaries? hmm, no we can't .... there's the case-problem ah yes so a CORE_foo is found as well as CoRe_FoO but I'm right that the whole classrep stuff breaks down to about 10%? (of what it is now) i can't say if it's 10% but it will be much smaller ok, so i'll think further this way the thing with the gnue.gsd and gnue.gcd is a bit tricky since we'd load everything from db we could replace gnue.gsd by gnue.gcd (which is much smaller and easier to maintain, as it won't contain gnue_id's and the like) the drawback would be, that gnue-readgcd cannot create database-backends I think we can well live with gnue.gsd yeah *** dcmwai has quit IRC johannesV: FWIW about memory leaks i ran a script on server that did put some 18000 new objects in db it started from 1.4% memory usage and ended at 10.1% i don't really know if it is a leak or only memory that is freed but not reclaimed back by server johannesV: did you have time to look at reordering commit and delete of referenced object? bbl *** holycow has quit IRC *** btami has quit IRC *** sjc has quit IRC lekma, no i had no time to do that reference/commit thing but i'm not recovered 100% anyway ... after two hours of working i need a bigger break (headache and the like) so i'm just doing small pieces of work atm ... :) leaks: can you document your testcase ? so i can use it for double-checking at least you might describe the script what it's doing johannesV: sorry to hear you're sick, i didn't know hope you will recover soon :) the doctor says it will take 6 to 8 weeks but i'm sure i can work fulltime much earlier ... :) *** jamest has joined #gnuenterprise what's the modern method for site config stuff in gnue? both INSTALL_PREFIX and GNUE-INSTALLED_SITE_CFG are amrked as depresiated depreciated is it 'depreciated' or 'deprecated'? which one is right? for our code? the latter most likely :) is there a big difference between the two words? in meaning yeah depreciate basically means to make obsolete or reduce value depricate is to put down just a sec http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=depreciate http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=deprecated things only a native-speaking one can answer well don't ever take my work on insight into the english language s/work/word you know both of these words appear to mean nearly the same in an EN-HU dictionary, and we (w/ btami) did not know whcih one is appropriate i didn't i thought you were making a joke :) me? a joke? never 8-)))) jamest: answering your question :) jamest: from gnue import paths reinhard: so it can't do external apps anymore? *** johannesV has quit IRC print paths.lib|scripts|data|config erm -- think i don't understand your question was thinking you try to get information about where gnue is installed at one time IIRC you could extend that info to include your custom appliations ah? didn't know that honestly, i can't recall the details but when I went to read the code I saw all the old stuff marked depreciated so figured I'd ask before i dug in well, so maybe the "new way" is lacking features that the old way had IIRC the change was necessary for proper installation of things probably so :) how hard do you think it'd be to convert the gnue setup.py to be more generic? and it's been more than a year IIRC, so please don't ask me too detailed ;-) so I could use it as the basis of installing other common derived apps? actually I think you should already be able to do that (mostly) last time i tried i think it had hard coded certain stuff into it if you tell me what exactly would be missing then maybe I could be more specific ;-) but that's been a year or more since I tried i don't have specifics yet but I'm converting most apps here to common based even toying around with jython a bit :) eeek :) and I have my pet project Adrius that i've got running again wow FWIW anyone interested can have a look at http://www.fsfe.org/ well, the building move is (hopefully) less than 6 weeks out and I'm regaining my life in fact, don't tell anyone it's a campaign but I fixed gnue's viewcvs module on ash bbl *** kilo has quit IRC and hope to clear out some twiki crap this week you can become a "fellow" of the fsf europe by signing up on the net an paying 120,- EUR whenever somebody signs up, the plone page packs up all info into an encrypted mail and sends it to an off-site database where a procmail script unpacks the mail and feeds into an appserver same happens when a paypal payment arrives appserver?!?! then appserver matches the payment with the registration data and sends an encrypted mail back to the plone page i wish there was a way I could use appserver with existing data as I have what I think is an ideal use for it where another procmail script enables mail forwarding and the login to the page as right now I have a bash script that sleeps 60 seconds, checks for new invoices, repeat i'd rather see something like appserver process it immediately on commit my problem is that I still need access to the invoice data from the accursed java app I've inherited it is really funny like I can now open a (gnue) form, select a user and click on a checkbox, and on a completely different machine a mail forwarding account is set up or deleted within seconds, and all communication goes via signed and encryted email how does appserver handle authentication? jamest: actually if you use very very bad tricks, there might be a way to do it with views no authentication in appserver so far planned for next milestone IIRC *** jcater_ has joined #gnuenterprise *** jcater has quit IRC *** johannesV has joined #gnuenterprise *** bluesbaron_ has joined #gnuenterprise *** bluesbaron_ has left #gnuenterprise *** titopbs has joined #gnuenterprise *** havoc has quit IRC *** havoc has joined #gnuenterprise *** mnemoc_ has joined #gnuenterprise *** mnemoc has quit IRC yep i am now a proud member of fsfe :) lekma: congrats :) *** havoc_ has joined #gnuenterprise *** wendall911 has joined #gnuenterprise reinhard, do you have another 5 minutes ? if i use 'data.connection.query ()' to fetch all records from gnue_* tables it will take about 0.5 seconds, and if i use GDataSource.DataSourceWrapper it will take 0.15 seconds which way would you prefer ? i'm tending to datasource-wrapper honestly I would prefer to find out whey data.connection.query () is so much slower :) s/whey/why/ oh, that's easy it's caching :) and that takes so much time? at least this is a big part of it, but i haven't used the profiler to determine it exactly the query () has to do the similair fetch, so it never could be faster; then it has to cach everything, do the merge-stuff ... I always liked daty.py being our only centralized interface to db access yes, i know this is why i'm asking ... ok, i'll take the profiler and look where the time get's lost ... I still think the difference should not be so big yeah, using data.py would mean three times as slow i wonder what's it do if you add import psyco psyco.profile() to the base application last week I was added psyco support to a few internal gnue-common based apps and visibly it seemed to at least double the db access speed if it did speed it up we could tell psyco exactly which pieces of gnue we'd want to precompile so that the memory hit isn't as huge and I'm 100% sure not crazy about going there, but there is always the possibility of using pyrex in gnue though that'd introduce C(++?) generated code into the mix which I'd like to avoid if at all possible bye all exit wrong window :) *** lekma has left #gnuenterprise *** wendall911 has quit IRC *** johannesV has left #gnuenterprise *** jcater_ has joined #gnuenterprise *** jcater has quit IRC *** btami has joined #gnuenterprise *** xet7 has joined #gnuenterprise What is the status of javascript / php client ? um i *think* seisel was working on it ok wow but it doesn't look like it's been worked on in years *** kilo has joined #gnuenterprise according to viewcvs so i seriously doubt it would function with the current code base does appserver run on Win2k server with postgres? that I don't know i know it works w/ postgresql but as for win2k i don't know maybe btami might know as he packages stuff for win32 or reinhard Hmm, there is installer for win32 and when I start appserver it shows some text and quits, maybe needs some config files xet7: appserver runs on win2k w/ pg i'v tested it with 8.0.1 running on XP ok night all *** btami has quit IRC *** tiredbones has quit IRC *** kilo has quit IRC night all *** reinhard has quit IRC *** xet7 has quit IRC *** jcater has quit IRC *** sjc has joined #gnuenterprise *** jamest has left #gnuenterprise *** jamest has joined #gnuenterprise *** titopbs_ has joined #gnuenterprise *** jcater has joined #gnuenterprise *** titopbs has quit IRC *** titopbs has joined #gnuenterprise *** titopbs_ has quit IRC *** xtian has joined #gnuenterprise *** sjc has quit IRC Hello there, Im havn some trouble with installing gnue. My issue right mow is about a file called 'pygettext'. The output goes somethin like: running install warning: cannot determine domain, not installing translations running buildCould not find 'pygettext'. Strange. running buildCould not find 'pygettext'. Strange. it shoult come with the python instalation. . . what platform? linux Gentoo looks like this exact same thing came up last sept ??? excuse me. sept? yip this may be of help i got the .pot file by changing XGETTEXT = pygettext to XGETTEXT = xgettext --language=Python in the makefile from the 2004-04-07 log found this via http://www.google.com/search?tab=gw&q=running%20build%20Could%20not%20find%20'pygettext'%20gentoo&hl=en& not sure if that's of help or not as I know nothing about the .pot file setup i'll check it. tanks 8) *** jamest has quit IRC *** xtian has quit IRC *** dcmwai has joined #gnuenterprise *** titopbs has quit IRC *** jcater has quit IRC *** dcmwai has quit IRC *** dcmwai has joined #gnuenterprise