*** holycow has quit IRC
*** holycow has joined #gnuenterprise
*** yure has quit IRC
*** sjc has joined #gnuenterprise
*** xet7 has quit IRC
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** holycow has quit IRC
*** reinhard has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** dimas has quit IRC
*** sjc has quit IRC
*** holycow has quit IRC
*** dimas has joined #gnuenterprise
*** mnemoc_ has joined #gnuenterprise
*** mnemoc has quit IRC
*** yure has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** neilt has joined #gnuenterprise
<reinhard> good morning all from US
<reinhard> jamest: any feedback before I release?
<jamest> nope
<reinhard> ok, shooting out the releases then
<jamest> with what I'm doing in GFDisplayHandler
<jamest> i'm thinking about breaking that into seperate files as it's too big/messy/etc
<jamest> was thinking about moving that and the GFKeyMapper into gnue.forms.input.
<jamest> with a gnu.forms.input.displayHanders.* making up the classes that are currently in GFDisplayMapper
<jamest> I'm also temped to move GFForm.py into GFObjects
<reinhard> I think I would be fine with all of that
<jamest> ok, thanks
<reinhard> in fact I'd love to see a gnue-forms 0.6 being cleanup'd and restructured like common 0.6
<jamest> that was the original goal for the 0.6.x releases
<reinhard> and I'd *very* love to see this done by != reinhard
<reinhard> :-)
<jamest> cleanup after we wrapped up a few features in forms
*** jcater has joined #gnuenterprise
<jamest> which i think after 2 years we can consider them "wrapped up"
<jamest> reinhard: i'm pretty much back :)
<jamest> just have to get my gnue legs under me again
<jamest> some cleanup and documentation work will help me with that
<jamest> i also like the idea of the gcd dir in appserver
<jamest> GFObjects is in effect the gfd dir of forms
<reinhard> yes
<reinhard> plus GFForm.py plus GFParser.py
<jamest> yeah
<jamest> also a gnue.forms.config with the GfConfig.py
* jamest wonders if eric will do refactoring across a project
<jamest> otherwise that's a lot of manual renaming :)
<reinhard> hmmm
<jamest> in netbeans I can rename/move a class
<reinhard> actually you could say *all* of gnue-forms is gnue-forms' gfd dir :)
<jamest> and it'll find all refernces to the class in the project and fix the code
<reinhard> so I'm not really sure if a move/rename makes sense
<jamest> GfInstance isn't
<reinhard> except GFForm -> GFObjects
<jamest> ok
<reinhard> just my 0.02
<reinhard> not trying to talk you into something or out of something
<jamest> i'm on the fence with that kind of change
<jamest> which is why I mentioned it here :)
<reinhard> So 0.6.0 is the next target release for gnue-forms?
<jamest> i'd be ok with that
<reinhard> ok
<jamest> but I do have to get input masks in there
<jamest> and finish up the query operator stuff
<reinhard> so you'd like to do a 0.5.x with that before heading for 0.6?
<jamest> doesn't matter much to me
<jamest> just listing things I need :)
<jamest> i've also got the work to do with navigator
<jamest> but that's more long term (even though I have the new phones setting on my desk :)
<reinhard> ok
<jamest> which reminds me
<jamest> does anyone know anything about making apps thread sage
<jamest> er, safe
<reinhard> I'd actually think of the "common ui thingy" as 0.7 or something like that
<reinhard> don't have global variables
<jamest> as I imagine if I want my user app to popup windows on incoming calls then it'd have to have some type of thread listening for it
<reinhard> only use thread safe functions
<reinhard> as to python, I don't think there's much to do except for removing all globals
*** wt has joined #gnuenterprise
<jamest> reinhard: also, the datasources still return mx.DateTime for backend date fields don't they?
<wt> jamest: new server up yet?
<jamest> wt: no :(
<jamest> the t1 isn't installed
<wt> ah
<jamest> i'm sorry
<wt> well, I am off to bed now
<wt> later
<jamest> you work nights?
<wt> yes
<jamest> as aren't you near cater?
<wt> yes
<jamest> I'm sorry
<jamest> er, i mean, ok
<wt> Umm, who's the lead on the erp stuff?
<jamest> i dunno who's leading the charge there
<wt> ah, well...bedtime |-)
<jamest> night
<reinhard> jamest: as to values common delivers from db: it depends on the dbsig2 module
<reinhard> technote 00016 gives an overview
<reinhard> (a quite shocking one, btw)
<jamest> ok, i'll read it
<jamest> i imagine it's something along the lines of "date time drivers in python are totally incosistant and suck arse"
<reinhard> right
<jamest> they suck so bad it hurts as it bites me time and time again
<reinhard> in fact there is no single driver for any database that handles fractional seconds consistently
<jamest> bingo
<jamest> that destroys updates
<reinhard> some drop the microseconds on read, some drop them on write
<jamest> on tables that don't have a PK
<reinhard> some just cut after 1/100 seconds
<jamest> as our update routines (didn't ) check the count of records updated
<jamest> to ensure that the update succeeded
<reinhard> some work for timestamp fields but don't work for time fields
<jamest> yes
<jcater> but who needs to store dates and times?
<jamest> we could take the point of view of the coder that created our sales app
<reinhard> best is that some even traceback when you try to store a datetime value with fractional seconds
<jamest> and store them all in varchars
<jcater> just do like I do at work and store an integer that's an offset from jcater's birthday
<reinhard> rofl
<jamest> lol
<jamest> reinhard: with a solution like that in place I vote we have jcater work out a fix for us as well
<jamest> with all his free time now that he's upper management
<reinhard> seriously, after collecting that list, johannes has sent about 5 bug reports including patches
<jamest> i know that pygresql just patch up to use python2.3 datetime
<reinhard> the bad thing is that even the backends themselves are inconsistent and differ a lot in the date/time types they provide
<jamest> not that I use that one
<reinhard> I guess that sooner or later all DBSIG2 drivers will do that
<reinhard> as it removes an external dependency
*** btami has joined #gnuenterprise
<jamest> well
<jamest> in the pygresql mailing list they said that
<jamest> (and this sucks)
<jamest> mx.DateTime license is not compatible w/ the GPL
<reinhard> gack
<jamest> yeah
<jamest> it hit the list yday
<jamest> i've not confirmed it yes
<jamest> er, yet
<jamest> here's the cut in paste
<jamest> Due to the license incompatibility of the GPL and the eGenix Public
<jamest> license (http://www.egenix.com/files/python/mxLicense.html#Public) i do
<jamest> not want to have the mx.DateTime dependency.
<reinhard> actually from reading the license, I would agree that it's non-GPL compatible
<reinhard> provided a python import counts as "linking"
<jamest> that's nice
<reinhard> because it says derivate works must be the same license
<reinhard> can you start a web page rebuild on ash?
<jamest> yes
<jamest> question about debug levels
<reinhard> I think the automatic rebuild still doesn't work
<jamest> i see in forms error msgs in 4, 5, and 6
<jamest> is there a pattern
<reinhard> technote 0014 defines
<reinhard> 4-6: can be used by the tools like forms, reports, appserver
<jamest> yes
<reinhard> within that range
<jamest> ?
*** SachaS has joined #gnuenterprise
<reinhard> I've generally used 4 for outmost level
<reinhard> which is, eg. for appserver, calls to the RPC interface
<reinhard> and would be in forms the top-level commands like "prev", "next", "commit", "rollback", "exit"
<reinhard> 5 i've used for stuff that might be interesting under some circumstances
<reinhard> and 6 for uidrivers
<reinhard> 4 could be for events on GFInstance level or so
<reinhard> AFAICT it's currently also used for startup
<reinhard> as I started to debug why it takes so long to startup a form
<reinhard> but didn't get very far
<reinhard> ---------
<reinhard> releases are out
<reinhard> jamest: feel free to mess with forms as you like
<jamest> bwahahahahaha
<jamest> reinhard: to do this right
<jamest>       gDebug(5,
<jamest>         "Entry %s: Received request to backspace but not in edit mode" %
<jamest>         self.entry.name )
<jamest> how can I wrapper that with _()
<jamest> or do i?
<reinhard> no
<reinhard> don't _() debug messages
<reinhard> they are for developers, not for users
<jamest> ok thanks
<reinhard> off for weekend
<reinhard> cu all
*** reinhard has quit IRC
*** sjc has joined #gnuenterprise
*** jcater has quit IRC
*** neilt has quit IRC
*** jamest has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<btami> win32 .exe files uploaded for new release
<btami> night all
*** btami has quit IRC
*** sjc has quit IRC
*** yure has quit IRC
*** yure has joined #gnuenterprise
*** kilo has quit IRC
*** SachaS has quit IRC
*** yure has quit IRC
*** jamest has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** jamest has quit IRC
*** wt has quit IRC
*** holycow has joined #gnuenterprise