*** holycow has joined #gnuenterprise *** sjc has joined #gnuenterprise *** holycow has quit IRC *** Amorphous has quit IRC *** reinhard has joined #gnuenterprise *** Amorphous has joined #gnuenterprise *** kilo has joined #gnuenterprise *** holycow has joined #gnuenterprise *** wendall911 has quit IRC good morning good morning kilo hi reinhard *** dcmwai has quit IRC *** johannesV has joined #gnuenterprise good morning all hi johannesV reinhard, what do you think of replacing checktype () by an 'assert' statement ? assert is a standard python function? right but the big thing is it can be turned off by a command-line option -O so the code dissapears completely ah * reinhard looking at docs well, acutally __debug__ builtin is set to false if using -O the difference would be the result of a 'failed' assertion, which is always an AssertionError instead of a TypeError that wouldn't matter too much and things like checktype (value, [StringType, UnicodeType, ...]) won't work is assert a function? ok, found it I think such things would still wokr well, anyway we could schedule such things for a later release ... since it's not crucial atm i've stopped with optimization of data.py since it needs more work anyway, like a changed chaching algorithm, that reference-problem-thingy ... i'll focus on an optimized classrepository using data.query () first I see something like and then i'll turn to that reference-stuff, since this builds on the repository assert hastype (value, [StringType, UnicodeType]) what's hastype ? checktype that doesn't raise an error but return False on non-matching types ah, ok, right but then again you would lose the information what value and what type the variable *really* has so we still have the function call hmm, assert might have a second argument, a error message to display if the assertion fails which has turned out to be very nice in case of errors yeah it's a bit weird the function call would not be there if compiled with optimization (AFAICT) but I'm still not sure if we should do that at all right, but if not, we would have two function calls, one for the assertion-test, and one for the error message yes, i'm not glad with it too that's why i haven't changed anything atm is it correct that it's not possible to turn off checktype at all? I mean replace it by an empty function? i think we keep that checktype () for the moment, as we have the same problem with gDebug anyway of course it is, but it's no win cause the body of checktype () executes faster that the function-call overhead ok, let's keep it like it is the only win would be to 'remove' the function call completely so you're working on the rewrite of classrepository now? i'd like to start with it, right ah ok ok for me i've created a new directory 'repository' which will contain the new repository implementation this way i can keep the old one besides if the new repository gets really much simpler then it might even make sense to do it in a single file (like data.py) reinhard, i've also thought about this ... do you have a 'good' name for that file ? repository.py ? (instead of a dir) yes I would have proposed exactly that hmm, ok ... :) I think I'll do a release before you commit that then i'm not yet sure about wether to create a Repository instance (providing access to the repo) or having only functions returning some dictionaries (but i'm tending to the instance) ok, i'm fine with the release *** btami has joined #gnuenterprise * gnue-gsdgen shouldn't rescan the module path johannesV: is that already fixed? * session.get () from the language interface does not properly raise an exception when the requested instance does not exist. that also would be great if you could fix those before repository rewrite ah, right, gnue-gsdgen must rescan the module path so we could include that in the release well, it does not rescan, but load the classrep as it needs this information to build dependancy-trees at some point it did rescan the other way would be to change gnue-gsdgen into an appserver-client gnue-gsdgen currently builds an instance of the sessionManager, which loads the classrepository the session.get () fix is no problem $ ggcvs -o test Classrepository wird geladen ... ************************************************************ Attempting to log into "GNUe Test Database" (gnue): Benutzername: gnue Passwort: ************************************************************ GNUe Klassendefinitionen werden geladen ... Datenbank-Schema wird aktualisiert ... Classrepository wird aktualisiert ... Module : 0 neu, 0 geändert, 3 unverändert Klassen : 0 neu, 0 geändert, 11 unverändert Eigenschaften: 0 neu, 0 geändert, 110 unverändert Prozeduren : 0 neu, 0 geändert, 19 unverändert Parameter : 0 neu, 0 geändert, 3 unverändert GNUe Sprachdefinitionen werden geladen Labels : 0 neu, 0 geändert, 43 unverändert. Meldungen: 0 neu, 0 geändert, 4 unverändert. johannesV: gnue-gsdgen *does* rescan the module path and re-import all gcd and gld files *** rwilco has joined #gnuenterprise that's the normal startup of sessionManager so if we build an instance of geasSessionManager ... can we change that? hmm, everything could be changed ... *lol* I would prefer gnue-gsdgen to not change anything in the database, no matter how silly you behave my problem was, for example, I have standard module path set to some dir with lots of files and I have a second appserver running with a module path pointing to nowhere because that appserver only uses 2 classes we can add another paramter to the sessionManager's constructor telling it wether to update the repo or not then I run gnue-gsdgen to export that data and forget to set --modulepath on gnue-gsdgen, and imported all other classes into the small appserver db right, that's really odd noone expects gnue-gsdgen to change something at all in your db and noone expects the spanish inquisition must go prepare lunch bbl :) ok, i'll fix these two bugs first thanks gnuenterprise, is a project to build a corporate MIS system? *** rwilco has left #gnuenterprise hmm, looks like the change of jamest broke dumpXML () *** empty_mind has joined #gnuenterprise does gnu enterprise work ? yes how goof good can it be used inplace of SAP or BAAN yes, 1-day turnover 8-)) empty_mind: gnue has no ready to run packages yet, just a dev environment, like forms, reports appserver, designer so you can build your SAP or BAAN if you have enough power/knowlegde/time... it means its not yet ready for comercial use it _IS_ but it's != SAP just something like Delphy Delphi instead building packages just started... if no ready to run package exists then why should i use it for my organization you don't have to it's a free dev toolset at the moment but we hope it will be soething like a free SAP/BAAN in the future empty_mind: btw what would you prefer: a ready-to-use system that you cannot customize to your own needs or a still-developing one that you can customize any time? bbl *** btami has quit IRC i would prefer a ready to use customizable system hmmm *** jcater has quit IRC *** tiredbones has joined #gnuenterprise *** empty_mind|away has left #gnuenterprise *** kilo has quit IRC *** johannesV has quit IRC *** jamest has joined #gnuenterprise reinhard: i was going to talk to you guys before I started adding stripPrefixes to all the various places in gnue make sure I was heading in a direction everyone was ok with but I see johannes already voted yes :) *** johannesV has joined #gnuenterprise hi jamest actually i had to fix only the signature of some dumpXML () functions to make it work with geasGsdGen :) you mean my change broke the app? *** johannesV_ has joined #gnuenterprise [08:20:37 am] you mean my change broke the app? *** johannesV has quit IRC jamest, actually the app created an object tree which get dumped to a file. since the app uses GContent objects the missing stripPrefix in GParserHelpers was a problem adding it there i though it would be fine to add it to all classes having a dumpXML anyone know how to unpack an rpm? johannesV_: sorry, i really didn't think my changes would have broken anything eventually I'd like to do away with the default of None and make the default the empty list but I didn't know a clean way to get all the various prefixes we're using in gnue apps chillywilly: i thought rpm had a built in arg for that no idea just want to look at postinst scripts I converted the OOo 2.0 beta rpms to debs with alien and installed them I have no fucking idea why on earth they made rpms, those bastards ;) can't you just untar the .deb and look there *** titopbs has joined #gnuenterprise *** holycow has quit IRC *** wendall911 has joined #gnuenterprise *** btami has joined #gnuenterprise *** tiredbones has quit IRC *** johannesV_ has quit IRC *** sjc has quit IRC *** johannesV has joined #gnuenterprise *** jamest has left #gnuenterprise *** johannesV has quit IRC *** tiredbones has joined #gnuenterprise *** jamest has joined #gnuenterprise *** kilo has joined #gnuenterprise *** titopbs_ has joined #gnuenterprise *** titopbs has quit IRC *** cilkay has joined #gnuenterprise *** btami has quit IRC *** titopbs_ has quit IRC *** titopbs has joined #gnuenterprise *** titopbs has quit IRC *** sjc has joined #gnuenterprise night all *** reinhard has quit IRC *** jamest has left #gnuenterprise *** tiredbones has quit IRC *** sjc has quit IRC *** jamest has joined #gnuenterprise *** kilo has quit IRC *** dcmwai has joined #gnuenterprise *** titopbs has joined #gnuenterprise *** jamest has quit IRC *** jcater has joined #gnuenterprise *** titopbs has quit IRC *** wendall911 has quit IRC