*** mnemoc_ has joined #gnuenterprise
*** mnemoc has quit IRC
*** reinhard has joined #gnuenterprise
*** chillywilly has quit IRC
*** Vee has quit IRC
*** chillywilly has joined #gnuenterprise
*** Vee has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** jerome has left #gnuenterprise
<kilo> good morning
<lekma> morning kilo
<kilo> hi lekma
*** btami has joined #gnuenterprise
<reinhard> good morning all
<reinhard> just FYI
<reinhard> after the release has been sent out yesterday, we are again in early breakage state
*** dcmwai has quit IRC
<btami> hi reinhard
<btami> the releases are ok on win32
<reinhard> great
<reinhard> thanks for testing
<btami> the sample.gfd problem was the good old comma as decimal separator
<btami> in my localised XP
<reinhard> oh crap, I forgot about that issue completely
<btami> just i forgot it to fix
<btami> ho problem
<btami> it's ok if i change it to point
<btami> and can't reproduce it on any other XP box
<btami> :)
<reinhard> probably dependent on service pack and whatever else...
<btami> btw. what are yours plan regarding breakage ?
<reinhard> I want to do a major cleanup of gnue.common.datasources
<reinhard> johannes is working on a complete rewrite of the class repository
<reinhard> both being purely internal changes with no visible changes for the user
<reinhard> except that some things might become a little faster
<reinhard> (say, factor 10) :)
<lekma> :)
*** sjc has quit IRC
<btami> ok, thx
<kilo> only by 10? scandal... 8-))
*** Vee2d2 has joined #gnuenterprise
*** Vee has quit IRC
*** btami has quit IRC
<reinhard> off to customer
<reinhard> l8r all
*** reinhard has quit IRC
*** kilo has quit IRC
*** jcater has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
<reinhard> jamest, jcater: any chance you can somewhat follow the things I do and tell me if I break something?
<jcater> my users tell me
<reinhard> you use svn?
<jcater> of course!
<jcater> what else would you use?
<reinhard> lol
<reinhard> and update regularly?
<jcater> no
<jamest> reinhard: whats up?
<jamest> what do I need to follow?
<reinhard> doing a little code cleanup in common
<jamest> I'll be following it then
<reinhard> already did the first commits
<reinhard> if there are methods or properties of an object that start with _
<reinhard> is it safe to assume that they are not used outside gnue? (e.g. in a trigger code of your forms)
<jamest> i'm 99% sure I only use exposed fuctions in triggers
<jamest> so yes
<reinhard> ok
<jamest> not so sure about all my common based stuff
<jamest> let me check something
<reinhard> I would like to increase encapsulation
<reinhard> for example instead of accessing RecordSet._modifiedFlags[fieldname] from the outside
<reinhard> go over defined procedures (setField for example)
<reinhard> and then, when it's really only used from within RecordSet, rename it to __modifiedFlags to make it really private
<reinhard> (if you agree with that plan)
<jamest> i'd like to see that
<reinhard> this would, for example, help to sort out those case problems we have throughout datasources
<jamest> yes
<reinhard> as you could do that lower() in a single point and it would be safe for everything
<jamest> i look clean in all recent gnue-common derived code
<jamest> so IMHO it'd be great to go for it
<nickr> hupo
<nickr> wow, this window was in backscroll land for like three days
*** tiredbones has joined #gnuenterprise
*** lekma has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> reinhard, you could use utils.CaselessDict to solve the case-problem ...
<johannesV> i can commit it if you like
<johannesV> there it is ....
*** sjc has joined #gnuenterprise
<reinhard> johannesV: thanks :)
<reinhard> johannesV: however, the problem is that some parts of the code consider the dictionary as classeles while others don't
<reinhard> s/classles/caseless/
<johannesV> but using the caseless dict it doesn't matter wether one uses a Key or a kEy or a KEY ...
*** someon has joined #gnuenterprise
<someon> Question...  if there is going to be a significant rewitre, can an implicit clause be added to the SQL strings?  ie. add an extra "where 'userGroup' in (self.user.groups)"  Such that self.user is the currently logged in user, and proerty groups is a list of the groups to which the user belongs...
<someon> 'userGroup' would then be a per-entry field that can control which groups can view the record...
<reinhard> as far as I am concerned, there is not going to be a significant rewrite
<reinhard> but rather a cleanup of what's here
<someon> Oops...  would need to also have "or 'userGroup' = $NULL$"
<someon> Fair enough.
<reinhard> I'm not planning about *any* new feature actually
<someon> I have two major problems to contributing to GNUe...  (1) no decent home 'net connection and (2) Don't know python.  I think that (2) is the bigger problem.
<reinhard> but maybe, as a result of this cleanup, implementing new features could become easier as the code would be structured better
<reinhard> (2) is something you can fix in an afternoon :)
<someon> That assumes that I have an afternoon :D
<reinhard> *lol*
<reinhard> well, the fact that you talk about contributing itself assumes that you have an afternoon :)
<someon> I lurk the logs on a regular basis, and have been asked by superiors at work if GNUe could be used...  It's lacking two things that the incumbant program has...  row-level security and column level security.
<someon> I would say that the implicit clause to the SQL string would take care of the first, but I'm not sure how to implement the second (column-level security)
<someon> <reinhard> well, the fact that you talk about contributing itself assumes that you have an afternoon :)
<someon> Point taken.
<someon> I'm not sure if matricies can be used efficiently in Python with SQL.  I don't see why it couldn't though.
<someon> ie if (1 2 3 4 5) in (2 8 10) then...  would be true...  (1 == 2) or (2 ==2) or (3==2)...
<someon> OK...  gotta run...  I'll keep an eye to the logs to see how badly the ideas get flamed :)
*** someon has quit IRC
<reinhard> jamest, jcater: strategy question
<reinhard> some objects in the dbdriver system (e.g. Connection) have methods that are called externally and implemented differently by the different drivers
<reinhard> e.g. Connection.close
<reinhard> currently, they are defined in the Base driver with pass, and overwritten by the drivers
<reinhard> now times are a-changing and there are (to stay with this example) things that should *always* be done on close (e.g. cleaning up references to let the garbage collection do it's work)
<reinhard> there's on point in the Base driver where such code could be put
<reinhard> I'd propose to generally (as a rule) do a close and a _close in such cases
<reinhard> where the close in the start just calls _close and _close is a placeholder to be overwritten by drivers
<reinhard> but if things have to be added in the base driver, it can be done in that close method
<reinhard> much like it's done for createResultset and _createResultset
<reinhard> what would you think?
<johannesV> wow, latest stats from repository-rewrite: time to load repo before rewrite (with debug-level:0-8) 16.334 seconds, after rewirte (same debug-levels): 1.320 seconds
<johannesV> appserver seems to work well with new repository, but i'll do further testing tomorrow ...
<reinhard> johannesV: excellent!
<reinhard> great work
<reinhard> would also be interesting how performance changed for "normal operation" of appserver
<reinhard> (load, store, request, fetch)
<johannesV> ok, i'm off for today ...
*** johannesV has quit IRC
<jamest> reinhard: makes sense to me
<reinhard> ok
*** SachaS has joined #gnuenterprise
*** SachaS_ has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<reinhard> jamest, jcater: can anybody please check why epydoc docs haven't been generated any more since november last year?
<jamest> i'll look in a bit
<reinhard> thanks
*** SachaS has quit IRC
*** ajmitch has quit IRC
*** ajmitch has joined #gnuenterprise
*** tiredbones has quit IRC
<jamest> reinhard: epydoc is running
<jamest> i've been looking into it between tasks
<jamest> but it's not giving any errors so I imagine it's being built in the wrong place
<reinhard> thanks
<reinhard> oh
<jamest> i may have to try and fix this when I get home
<reinhard> it's expected to be in http://www.gnuenterprise.org/tools/common/docs/api/
<SachaS_> night
<jamest> that url claims to have been created today
*** SachaS_ has quit IRC
<jamest> at about the time I did my 1st test run
<reinhard> yeah, it *is* current now
<reinhard> so probably it simply doesn't get started automatically?
<jamest> i just hand ran the cronjob script
<jamest> which would imply some sort of environment setup that a login shell has vs a shell created by cron
*** kilo has quit IRC
*** jamest has left #gnuenterprise
<reinhard> night all
*** reinhard has quit IRC
*** jamest has joined #gnuenterprise
*** sjc has quit IRC
*** deci has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** deci has quit IRC
*** newbie has joined #gnuenterprise
<newbie> hi
<newbie> hi
*** newbie has quit IRC
*** deci has joined #gnuenterprise
*** deci has quit IRC
*** deci has joined #gnuenterprise
*** deci has left #gnuenterprise
*** holycow has joined #gnuenterprise