*** reinhard has joined #gnuenterprise
<reinhard> good morning all
<reinhard> jbailey: any news on debian packages?
*** johannesV has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<kilo> good morning
<johannesV> hi kilo
<kilo> hi johannesV
<kilo> johannesV: grrrrrr
*** lekma has joined #gnuenterprise
<lekma> hello everyone
<kilo> hi lekma
<lekma> hi kilo
*** btami has joined #gnuenterprise
<johannesV> kilo, sorry ...
<kilo> np
*** holycow has joined #gnuenterprise
*** mo has joined #gnuenterprise
<mo> hi there
<reinhard> hi mo
*** sjc has quit IRC
<lekma> johannesV: the leaks are not visible any more with generated gnue-forms... i still got some with the xul generation code, do you have any hints on chasing them??
<lekma> on a side note: am i wrong when saying that now every property of a session.find
<lekma> is in fact a SELECT in db??
<reinhard> lekma: this should not be the case
<reinhard> there should be a single select that gets all properties at a time
<lekma> when debugging : session.find(klass, cond, sort, [prp1, prop2, prop3]
<lekma> DB001: 0:08:52.238 [DataObject:105] DB-SIG database driver backend initializing
<lekma> DB001: 0:08:52.239 [GConnections:296] Attaching to DataObject_Object (object)
<lekma> DB001: 0:08:52.242 [Connection:288] DBSIG2 Statement: SELECT xul_type FROM xul_items WHERE (((gnue_id = '99999999999999999999999999920802')))
<lekma> for all props
<reinhard> do you use absolutely current SVN?
<lekma> in this example xul_type is on ly one prop of a long list
<reinhard> there was a bug that could have exactly that symptom
<lekma> 6682
<holycow> lekma, are you working on an xul driver for gnue server?
<reinhard> lekma: just a second
<lekma> holycow: not at the moment, i'm working on a xul client for appserver for a customer, but maybe after if succesful, we will try to make a generic gnue-xul client
<holycow> oh neat! really?
<holycow> wow thats cool :)
<holycow> i would be very interesting in hearing about your results
<lekma> big IFS in all this
<holycow> *nod*
<holycow> lekma, why not using gnue forms?
<reinhard> lekma: lol
<reinhard> you are unlucky
<lekma> there are screenshots at http://www.orwex.net/gnue-dev/articles.jpg and http://www.orwex.net/gnue-dev/articles2jpg
<reinhard> if it's really the bug I'm thinking of
<reinhard> it was introduced in 6682 and fixed in 6683
<lekma> lol
<lekma> i'll try and svn up
<reinhard> would be great if you could confirm that it works again
<kilo> @roulette
<bigbrother> kilo: *click*
<holycow> kilo, heh :)
* holycow waits for the screencaps to load
<holycow> *tap* *tap* *tap*
<holycow> >_>
<kilo> holycow: play roulette until they load... 8-))
<lekma> reinhard: it seems to work again with 6686, but now it seems to me that properties values are not cached anymore when specified in a find, cause i see a SELECT for properties that are supposed to be already available
<lekma> am i wrong?
<reinhard> please let me test
<reinhard> I didn't test the latest changes yet
<reinhard> lekma: I cannot reproduce that behaviour
<reinhard> also I am confused
<reinhard> because what you describe now is the same symptom than you had before?
<lekma> reinhard: nope, before i when find was triggered i had dozen of select to satisfy it
<lekma> now only one select is done when find is triggered
<lekma> but when later in the code i do object.property i see a SELECT
<reinhard> ah ok
<reinhard> I think I still cannot reproduce it
<reinhard> even with a procedure call on appserver side
<reinhard> the property was in the list for find()?
<reinhard> and that code is running in the same session as the find() runs?
*** holycow has quit IRC
<reinhard> however
<reinhard> I pass the ball over to johannesV
<reinhard> have to leave for an hour or two
<reinhard> bbl
*** btami has quit IRC
<johannesV> lekma, there seems to be a bug or two in there (i think in appserver) ... i'll switch into hunting mode now ... :)
*** johannesV_ has joined #gnuenterprise
*** reinhard has quit IRC
*** reinhard has joined #gnuenterprise
*** johannesV has quit IRC
*** kilo has quit IRC
*** wayneg has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<johannesV_> lekma, i can't find a problem
<johannesV_> (but have found another one in datasource.drivers.Base.ResultSet)
<lekma> johannesV_: i have a list provided by a find
<lekma> and i thought that every properties
<lekma> specified in the find was cached
<lekma> and immediatly available
<lekma> but if i pass this objects list
<lekma> to another proc in the same class
<lekma> when i access properties of the object
<lekma> i see a SELECT triggered to db
<lekma> is this normal behaviour??
<johannesV_> how do you pass this object list to the procedure ? which param-type do you use ?
<lekma> in fact i don't even pass it, i build a list with the first procedure and then manipulate it with the other one
<johannesV_> but how can the other procedure access the list ?
<lekma> it's a 'global' variable (a list, global to the class)
<lekma> initialize in __init__
<johannesV_> so you talk of a python class
<lekma> yep
<johannesV_> hmm
<johannesV_> is there a commit or a rollback in between ?
<lekma> i was talking about external python code
<lekma> hmmm
<lekma> let me check
<johannesV_> these two actions clear the cache
<lekma> yep, that was it there is a rollback in between
<lekma> sorry
<johannesV_> ok :)
<johannesV_> np
<reinhard> lekma: rollback invalidates the cache
<reinhard> because changes from outside the transaction will get valid at that point
<reinhard> so appserver *must* re-select the data
<reinhard> to see if something has changed meanwhile
<reinhard> but thank you for asking that question
<lekma> :)
<reinhard> it made us learn what to ask first ;-)
<lekma> there may still be something wrong (maybe in my perception of all this)
<lekma> even without the rollback i see:
<lekma> DB001: 0:00:25.721 [DataObject:105] DB-SIG database driver backend initializing
<lekma> DB001: 0:00:25.722 [GConnections:296] Attaching to DataObject_Object (object)
<lekma> DB001: 0:00:25.725 [Connection:288] DBSIG2 Statement: SELECT xul_style FROM xul_elements WHERE (((gnue_id = '92621470359225398349175027112456')))
<lekma> DB001: 0:00:25.726 [Connection:289] DBSIG2 Parameters: None
<lekma> for a property that is supposed to be cached
<lekma> and for every object in the find result
<lekma> is it the cache that is accessed?? or the db
<reinhard> if you see the select statement, the db is accessed
<reinhard> idea
<reinhard> johannesV_: what would you think about providing a method to output the content of the cache to a file for debugging purposes?
<reinhard> or add some high debug level output
<reinhard> "adding to cache: ...."
<reinhard> "reading from cache: ..."
<reinhard> "searching in cache: ..."
<reinhard> "found | not found in cache: ..."
<reinhard> etc
<lekma> would it be that, in fact, the list i'm looping in is not the direct result of a find, but a list built with every result object of a find
<lekma> i mean if i do
<reinhard> lekma: no, shouldn't be
<lekma> for x in find(klass,...):
<lekma>   otherlist.append (x)
<lekma> would it be the cause of the cache invalidation
<reinhard> lekma: no, the cache should survive there
<johannesV_> debug-output of cache ...
<johannesV_> i think adding gDebug at a given level is easier than it's own debug-file
<reinhard> that's what I actually meant :)
<reinhard> very high level (7, 8, or 9)
<johannesV_> right
<reinhard> with messages for adding, searching in cache, found/not found, cache clear...
<reinhard> maybe if not found in cache, even detail info like
<reinhard> class not in cache - instance not in cache - instance in cache, but field not cached (cache for this class is:....)
<reinhard> and please don't forget to import GDebug so data.py remains self-contained
<johannesV_> i cannot locate that f** focus problem ...
<johannesV_> how can i switch back to a given revision for a complete trunk (like gnue-forms) ?
<reinhard> svn update -r 1234
<reinhard> IIRC
<johannesV_> thanks, just found it myself
<johannesV_> do i need to remove files first ?
<johannesV_> ok, the bug was there on 0.5.8 release
<wayneg> is it common to get debug lines like: "DB005: 0:00:43.349 [DataObject:234]  WHERE ((1 = 0))" ?
<wayneg> or does this suggest something is wrong with the form i've created ?
<johannesV_> in 0.5.7 it disappears ..
<johannesV_> wayneg, this means you have --debug-level=5 (at least) given at the command line
<johannesV_> the condition WHERE ((1=0)) is an 'impossible' one to create an empty result set
<johannesV_> so you haven't done something wrong
<wayneg> :) hi johannesV_
<wayneg> so i should disregard ones like "DB005: 0:00:45.958 [DataObject:343] SELECT id FROM contact_email WHERE ((1 = 0))" also?
* chillywilly tugs on johannesV_'s tail
<jamest> wayneg: yes
<wayneg> i realise this will never return anything ... just trying to understand why such a query is being generated
<jamest> 1=0 always is used to create empty resultsets
<jamest> creating an empty result set is the exact same logic as one containing data
<jamest> the 1=0 query ensures all the various things we do in datasources get done even for empties
* jamest can't recall exactly what those things are as 1=0 query has been there for years
<wayneg> ok, thanks
<jamest> i think it properly sets up things like key fields
<wayneg> that's not where my problem is then :)
<johannesV_> or at least make a cursor.getDescription () available .. (in DBSIG2)
<jbailey> reinhard: You truly need to ping ajmitch.  I just upload what he gives me and I haven't heard anything yet.
<reinhard> jbailey: ok, thanks
<johannesV_> reinhard, it's working for both, dialogs and forms now ...
<johannesV_> the mainWindow.show_all () changed the focused widget
<reinhard> congrats
<reinhard> you showed some excellent bug finding skills today :)
<wayneg> IIRC i think ajmitch is away from home at the moment (in Melbourne working) FWIW
<johannesV_> :)
<johannesV_> bbl
*** jcater has joined #gnuenterprise
*** wendall911 has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<kilo> @weather LHUD
<bigbrother> kilo: The current temperature in Szeged, Hungary is 47°F. Conditions: Partly Cloudy. Humidity: 74%. Dew Point: 41°F. Wind: SSW at 7 mph (11 km/h). Pressure: 30.22 in (1023 hPa). Visibility: 11.0 miles (18.0 kilometers). UV: 0 out of 12
*** holycow has joined #gnuenterprise
<lekma> reinhard or johannesV_ : does appserver opens a connection to db for each and every find/request? or does it use one that is initialized at Session.open time?
<reinhard> appserver opens a connection per session
<reinhard> that connection is reused througout the session
<reinhard> do you use postgres?
<reinhard> then you can use postgres.log to see the sessions
<lekma> yep
<lekma> yep we've seen it it was just to be sure...
<reinhard> actually we try to be as smart as possible to use the db effectively
*** mo has quit IRC
*** sjc has joined #gnuenterprise
*** johannesV_ has quit IRC
*** kilo has quit IRC
*** kilo_ has joined #gnuenterprise
<lekma> night all
*** lekma has quit IRC
<involved> hi
<involved> where can i get some functional examples?
<involved> like those in the screenshots..
*** cilkay has quit IRC
<jamest> involved: the sample forms are in gnue-forms/samples dirs
<jamest> sample appserver stuff I dunno
<jamest> there is a gnue-contrib repository that contains appserver/gnue-navigator/gnue-forms sample
<chillywilly>  anyone know of any pretty print module that will print out data structures like PHP's print_r or perl's Data::Dumper?
<jcater> >>> import pprint
<jcater> >>> print pprint.__doc__
*** cilkay has joined #gnuenterprise
<chillywilly> pprint?
<chillywilly> doh
<chillywilly> yea
<chillywilly> google told me that
<chillywilly> nm then
<chillywilly> it'd be nice if the thing handled all types including arbitrary objects
<reinhard> appserver samples are in gnue-appserver/samples dir
<reinhard> consequently ;-)
<involved> thanks
<involved> i am using the debian package..
<involved> kinda confused..
<involved> i'll get the source..
*** brush has joined #gnuenterprise
*** jamest has quit IRC
<brush> greetings.  apologies if this is the wrong place, but i'm thinking of developing and customizing gnue apps to manage a nonprofit's finances, largely for scalability reasons, commitment to open source, and because gnucash seems not to be going in a business direction.  would anyone mind answering soem questions?
<wayneg> brush, just throw them out there and if someone can answer i'm sure they will. :)
* brush nods.
<brush> first, the website notes that the packages are less developed than the tools, but what exactly does that mean?  is there an accounting package that ius functional, and that could be customized initially with relatively little overhgead?
<brush> i couldn't quite figure that out from the site.
<brush> second, my knowledge of python is limited, though i have extensive c and php experieince.  how steep is the learning curve?
<brush> third, is there any movement towards data exchange with gnucash, which seems to have a good frontend?  i'm new to bopth, and it seems that gnucash may have limited data portability, but just in case...
<brush> and finally, is there active development of sepcific financially oriented reports, realtively pretty etc., that i could contribute to, or is it likely that they will have to be developed myself?
<wayneg> no there isn't yet an accounting package ... if you program c, python should be a breeze
<wayneg> third ... i'm not a developer so i can answer that ... although none that i know of
<wayneg> fourth ... gnue has a reporting tool that you can use
<holycow> brush currently the development is focused a) building up the robustness of the toolset
<holycow> b) secondarily using that toolset for the developers own needs, gnue is used in a number of businesses i understand
<brush> thanks wayneg!  re: the reporting tool: i imagine it's a mechanism for producing reports, but my question is primarily around esthetics.  i'm wondering w\hether other folk have already made really pretty blance sheets, annual reports, cash flow preidctions, etc., or whether i would be doing that largely from scratch ...
<holycow> for specific needs
<holycow> i doubt they have brush as no accounting package exists per se
<wayneg> brush, it appears in gnue a lot easier task then in gnucash though
<wayneg> ie you don't need to know guile or whatever that programming langauge is that gnucash uses
<brush> ok.  that makes sense, holycow.  so here's a doozy of a question: any idea how much time upfront it might tke to implement a basic accounting app that could get us going ...
<holycow> particularly as in gnue, the framework is open, you are creating the application your self, you are modifying the forms
<holycow> in gnucash they built the framework for you and you haveto figure out how to use it
<holycow> wayneg, gnucash uses guile for report building?
<holycow> *meh*
<brush> w: scheme.  yeah, i dopn't like ti much.  h: true, that's what i'm nervous about in gnucash.  doesn't seem too flexible.
<holycow> brush well, i'm going to start off using sql-ledger.org
<holycow> its free and full fledged accounting system
<wayneg> thanks brush  ... no holycow it's scheme :)
<holycow> i would say that it would be a good idea to 'port' sql-ledger than start from scratch
<brush> holycow: and then develop gnue apps that can use the same backend?  would that work?
<holycow> wayneg, ah! danke :) didn't know
<holycow> brush, *nod*
<holycow> actually they both use postgres
<holycow> so
<holycow> you wouldn't even haveto change the database structure
<brush> i've primarily used mysql; i imagine it doens't make too much difference?
<holycow> you can completely emulate the db structure (provided its looked at by a knowledgeable person)
<holycow> and then your left porting the modules
<holycow> i think you will like postgres much more :) i'm not a developer but as a noob i find postgres much easier than mysql
* wayneg agrees
<brush> ok, cool.  i'll checmk into sql-ledger.  is it o-s?
<holycow> so if you have resources ... perhaps starting off with sql ledger as something to base it on ?
<holycow> yep
<holycow> gpl
<holycow> perl/web based frontend
<holycow> postgres backend
<holycow> once you have sql-ledger type thing in gnue
<holycow> boy
<holycow> the door is wide open
<brush> oh, right,  i tend not to love perl too much, so i think that's why i didn't focus on it .. but that's ok.
<holycow> erp here we come :)
<holycow> brush... to note:
<holycow> the guy that wrote sql-leger is here in canada
<holycow> he makes a living off of it supporting it
*** jcater has quit IRC
<holycow> i am certain that with a framework like gnue you could turn around the effort and consider a business consultancy perhaps, if thats your cup of tea
<brush> holycow: interesting idea.
<holycow> and he's been doing sql-ledger support for many years now so the business idea is sound, of course getting sales is always tricky
<brush> i'm not sure if i have the rank energy to devote to fully porting an entire application, but who knows.
<holycow> for one, i would love to have sql ledger on gnue, with proper sequrity structure created as well
<holycow> and i would pay for support and or setup my own consultancy for it
<brush> how many businesses are using gnue, that y'all know fo?
<holycow>  most people here are interested in extending into the erp side of things and help businesses out
<holycow> brush *nod* just mentioning, its accounting to begin with :) i donno how many, the devs might have a better idea ;)
<holycow> wayneg, didn't mean to drown you out :)
*** jcater has joined #gnuenterprise
<holycow> ehe, as you can tell i'm a gnue groupie >_>
<wayneg> :) holycow not a problem
* brush thinks that's grteat.
<wayneg> brush, i'm starting my own business ... and i'm *very slowly* building my own system
<wayneg> only just started
<brush> ok.  much to look through and think about.  certainly, if i start porting accounting apps from sql-ledger or elsewhere, i'll be back begging for help.  :)
<holycow> wayneg, me too
<holycow> i need erp bad
<holycow> lol brush :)
<brush> wayneg: how's it going?
<holycow> well look at it this way
<holycow> we're all looking at starting somewhere in the erp chain
<holycow> hopefully we can meetin the middle someplace
<holycow> while taking care of current needs as well
<wayneg> *slowly :)
<wayneg> but i do everything slowly :))
<brush> hmmm.   how many other epople are working on the package side of things?  how many, that is, involved in open sourcing it?
<holycow> well i need to do lists, basic contact manager
<holycow> basic issue tracking
<holycow> basic inventory asset management
<holycow> whatever i write will be gpl'd
<holycow> however, i haven't started yet >_<
<holycow> ehe ^_^
* brush is looking at sql-ledger for a sec.
<wayneg> brush, the thing about packages (eg. accounting) is making them so that they are broad enough to be used by everyone
<wayneg> eg. all the different tax systems around the world ... etc...
<holycow> sql-ledger has many german customers
<holycow> as well as canadian
<wendall911> wayneg: and all the states/province/local tax structures
<holycow> the app would need to be modular
<wayneg> yes
<wendall911> accounting is a nightmare
<holycow> so you could upgrade rates and rules for various countries?
<wendall911> I vote we just get rid of all taxes...then I could just use my checkbook register
<holycow> wendall911, heh :)
<wayneg> :)
<holycow> i like linus' perspective in this
<holycow> think small and applicable
<holycow> if you think big you overdesign and never get stuff done
<wayneg> holycow, that is a BIG problem for me
<holycow> i would say if brush solves his own needs, the job is done, hopefully we learn and refactor as necessary along the way
<holycow> wayne, don't forget you can actually just install sql-ledger
<holycow> and port later?
<holycow> it has a postgres backend, no reason you cannot write gnue apps around it
<wayneg> yeah ... i've taken sql-ledger for a spin ... there was something i didn't like about it
<wayneg> although there were many positives
<wendall911> you must have looked at the code ;)
<wayneg> haha
<holycow> lol i've heard the perl is a nightmare, but then again, perl coders tend to be 'edgy' to begin with <_<
*** kilo has joined #gnuenterprise
<wayneg> no ... i couldn't remove something eg. a customer or a product or something like that ... which just really rubbed me the wrong way
<holycow> nothing that can't be fixed, its open source afterall :)
<holycow>  http://www.theregister.co.uk/2004/11/17/letter_piracy_china/  <-- cool article
<wayneg> true ... but i thought for my *curently small business*, how hard can it be to roll your own with gnue ;)
<holycow> probably not hard, but accounting doesn't strike me as a roll your own thing for anything beyond the most basic thign
<holycow> you can roll a calendar, a to do list, customer management stuff, accounting has 'rules' *yeck*
<wayneg> holycow, either your making money or your not ... concept seems pretty simple to me
<wayneg> :)
<holycow> lol ;)
<holycow> well, you got a point
<wayneg> anywho ... it's been great chatting ... but i gotta go ... later
<wayneg> afk
*** kilo_ has quit IRC
*** kilo has quit IRC
<brush> ?
<brush> thanks folks for all the help, wayng and holycow esp.
<brush> i've been look at sql-l and we've see what can be done.
<holycow> cool, no worries
<holycow> do stick around and let us know what you end up doing :)
<brush> sure!
<brush> (with echoes) i'll be back.  ;)
<brush> cul
*** brush has quit IRC
<holycow> :)
*** sjc has quit IRC
<reinhard> night all
*** reinhard has quit IRC
*** holycow has quit IRC
*** cilkay has quit IRC
*** wendall911 has left #gnuenterprise
*** jcater_ has joined #gnuenterprise
*** jcater has quit IRC
*** holycow has joined #gnuenterprise
*** jamest has joined #gnuenterprise
*** wayneg has quit IRC
*** wayneg has joined #gnuenterprise
*** holycow has quit IRC
*** wayneg has quit IRC
*** jamest has quit IRC