*** btami has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** btami has quit IRC
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** besonen has quit IRC
*** cilkay has joined #gnuenterprise
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** sjc has quit IRC
*** holycow has quit IRC
*** sjc has joined #gnuenterprise
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** kilo has joined #gnuenterprise
<kilo> good morning
<johannesV> hi kilo
<kilo> hello austria
<shmooz> which web end user interfaces are available?
<reinhard> shmooz: AFAICT, none
<reinhard> shmooz: several have been started, but none is fully functional
<reinhard> and for most main developers, web is not a target
<shmooz> so what UI is most used by non techies?
<reinhard> gtk2 is most advanced
<reinhard> windows is very close
<shmooz> gnue-designer ?
<reinhard> gnue-designer currently only supports the wx UI (usable under Windows and X)
<shmooz> so once installed is there anything for people in this organization to use besides gnue-designer?
<shmooz> please somebody say yes there is - look it up http something
<shmooz> ok how does one actually use the financials?
<shmooz> really am i lost here? am I missing something?
*** wt has joined #gnuenterprise
*** sjc has quit IRC
<reinhard> shmooz: sorry i'm on the phone
<reinhard> will answer as soon as i can
<shmooz> ok thanks bud, I thought everyone went to sleep or
<shmooz> was giving the silent you shold know the obvious here ;^)
<kilo> @weather LHUD
<bigbrother> kilo: The current temperature in Szeged, Hungary is 34°F. Conditions: Partly Cloudy. Humidity: 82%. Dew Point: 31°F. Pressure: 30.08 in (1018 hPa). Visibility: 6.0 miles (10.0 kilometers). UV: 0 out of 12
<wt> @weather MEM
<bigbrother> wt: The current temperature in Memphis International, Tennessee is 54°F (2:53 AM CST on November 16, 2004). Conditions: Overcast. Humidity: 77%. Dew Point: 46°F. Pressure: 30.45 in (1031 hPa). Visibility: 10.0 miles (16.1 kilometers). UV: 0 out of 12
<wt> @help
<bigbrother> wt: help [<plugin>] <command>
<wt> @lsit
<wt> @list
<bigbrother> wt: Admin, Alias, Amazon, Anonymous, Babelfish, BadWords, Bugzilla, Channel, ChannelLogger, ChannelStats, Config, Ctcp, Currency, DCC, Debian, Dict, Ebay, Factoids, Filter, Format, Fun, FunDB, Google, Herald, Http, Karma, Later, Lookup, Math, Misc, Network, Note, Owner, Poll, Python, RSS, RootWarner, Scheduler, Seen, Services, Sourceforge, Status, Todo, Topic, URL, Unix, User, UserInfo, (1 more message)
<wt> @Admin
<wt> oops
<wt> @anonymous
<bigbrother> wt: (anonymous <command> [<args> ...]) -- Command dispatcher for the Anonymous plugin. Use 'list Anonymous' to see the commands provided by this plugin. Use 'config list plugins.Anonymous' to see the configuration values for this plugin. In most cases this dispatcher command is unnecessary; in cases where more than one plugin defines a given command, use this command to tell the bot which plugin's command to use.
<wt> @ebay
<bigbrother> wt: (ebay <command> [<args> ...]) -- Command dispatcher for the Ebay plugin. Use 'list Ebay' to see the commands provided by this plugin. Use 'config list plugins.Ebay' to see the configuration values for this plugin. In most cases this dispatcher command is unnecessary; in cases where more than one plugin defines a given command, use this command to tell the bot which plugin's command to use.
*** btami has joined #gnuenterprise
<wt> @list
<bigbrother> wt: Admin, Alias, Amazon, Anonymous, Babelfish, BadWords, Bugzilla, Channel, ChannelLogger, ChannelStats, Config, Ctcp, Currency, DCC, Debian, Dict, Ebay, Factoids, Filter, Format, Fun, FunDB, Google, Herald, Http, Karma, Later, Lookup, Math, Misc, Network, Note, Owner, Poll, Python, RSS, RootWarner, Scheduler, Seen, Services, Sourceforge, Status, Todo, Topic, URL, Unix, User, UserInfo, (1 more message)
<wt> @http
<bigbrother> wt: (http <command> [<args> ...]) -- Command dispatcher for the Http plugin. Use 'list Http' to see the commands provided by this plugin. Use 'config list plugins.Http' to see the configuration values for this plugin. In most cases this dispatcher command is unnecessary; in cases where more than one plugin defines a given command, use this command to tell the bot which plugin's command to use.
<wt> @list http
<bigbrother> wt: acronym, bender, cyborg, doctype, extension, freshmeat, geekquote, headers, kernel, netcraft, pgpkey, size, stockquote, title, and zipinfo
<wt> @todo
<reinhard> shmooz: of course there's a lot more to use than gnue-designer
<kilo> wt: http://supybot.sourceforge.net/docs/commands.html
<reinhard> appserver, forms, and reports are in a fairly usable state
<kilo> and common
<reinhard> and even navigator
<reinhard> well, common is not something an "end-user" would "use"
<reinhard> several people are developing application with these tools
<kilo> depends on the definition of 'end-user'
<reinhard> financials is just being developed, so not yet usable
<wt> kilo, don't think he means developer
<wt> base is not either
<wt> or is it?
<reinhard> wt: for me, base is for packages what common is for tools
<shmooz> ok
<wt> we need to get .glds in for the base
<kilo> @monologue
<bigbrother> kilo: Your current monologue is at least 1 line long.
<shmooz> so really to have an end useer usable install most of the packages have to be installed aswell.
<kilo> a
<kilo> b
<kilo> c
<kilo> @monologue
<bigbrother> kilo: Your current monologue is at least 4 lines long.
<reinhard> shmooz: if you mean "accountant" or "secretary" with "end user"
<reinhard> then we're not yet there
<wt> reinhard, can you make a scripts dir in gnue-packages please?
<reinhard> is ash alive again?
<btami> yep
<wt> reinhard, errr....gnue-packages/base, I mean
<wt> I want to make a script that installs the base packages in the right order
<shmooz> well as opposed to accountant and secretary how about sales people and service desk
<kilo> wt: ok, will do that
<wt> reinhard, is there any way to list the forms on a server?
<reinhard> find / -name "*.gfd"
<reinhard> :)
<wt> kilo, also, could you move the item-vat stuff to financials
<wt> prolly under tax
<reinhard> shmooz: the packages are just being built
<reinhard> none of them is acutally usable
<reinhard> what we have is the tools
<reinhard> like forms, reports, etc
<kilo> item-vat to financials? ok
<wt> I have a simple item-C.gld
<kilo> plz share with me
<kilo> what does 'prolly under tax' mean
<shmooz> hmmmm arethose packages intended to be accessible remotely preferably via http
<wt> kilo, the item-vat should prolly go under financials/tax
<kilo> ok, thx
<kilo> @roulette
<bigbrother> kilo: *click*
<btami> @roulette
<bigbrother> btami: *click*
<kilo> reinhard: plz try roulette
<reinhard> shmooz: gnu enterprise is clearly not a project to write a web based accounting program
<kilo> wt: plz try roulette
<reinhard> @roulette
<bigbrother> *BANG* Hey, who put a blank in here?!
* bigbrother reloads and spins the chambers.
<btami> :))))))
<reinhard> lol
<kilo> rotfl
<btami> hehe, kilo reads supybot docs :)
<wt> kilo, is VAT the generic term for sales tax?
<shmooz> reinhard, well how about a small general tech services group
<kilo> i think so. VAT = value added tax
<reinhard> shmooz: i meant gnue is not primarly targeted at web applications
<wt> @roulette
<bigbrother> wt: *click*
<wt> what is roulette?
<wt> oh
<wt> I get it
<btami> @roulette
<bigbrother> *BANG* Hey, who put a blank in here?!
* bigbrother reloads and spins the chambers.
<btami> :(
<kilo> wt: http://supybot.sourceforge.net/docs/plugins/Fun.html
<kilo> @roulette
<bigbrother> kilo: *click*
<wt> @roulette
<bigbrother> *BANG* Hey, who put a blank in here?!
* bigbrother reloads and spins the chambers.
<kilo> lol
* wt hurts
<wt> @roulette
<bigbrother> *BANG* Hey, who put a blank in here?!
* bigbrother reloads and spins the chambers.
* wt hurts again
<wt> @roulette
<bigbrother> wt: *click*
<btami> rotfl
<kilo>  /msg btami he did not learn from the first one
<btami> or has 9 lifes, like a cat
<wt> I have more than 9
<wt> :-P
<kilo> @languages
<bigbrother> kilo: Portuguese, Chinese, German, Spanish, Japanese, French, English, Korean, and Italian
<kilo> @coin
<bigbrother> kilo: heads
<kilo> @uptime
<bigbrother> kilo: I have been running for 18 hours, 23 minutes, and 49 seconds.
<kilo> @cpu
<bigbrother> kilo: I have taken 123.88 seconds of user time and 6.32 seconds of system time, for a total of 130.20 seconds of CPU time. My children have taken 0.00 seconds of user time and 0.00 seconds of system time for a total of 0.00 seconds of CPU time. I'm taking up 10960 kB of memory.
<kilo> @cmd
<bigbrother> kilo: I offer a total of 393 commands in 51 command-based plugins.  I have processed 28 commands.
<kilo> @dict licorice
<bigbrother> kilo: web1913 and wn responded: wn: licorice n 1: deep-rooted coarse-textured plant native to the Mediterranean region having blue flowers and pinnately compound leaves; widely cultivated in Europe for its long thick sweet roots [syn: {liquorice}, {Glycyrrhiza glabra}] 2: a black candy flavored with the dried root of the licorice plant [syn: {liquorice}]; web1913: Licorice (4 more messages)
<reinhard> kilo: fyi, gsscvs does take multiple filenames (IIRC)
<kilo> i remember that way also, but i prefered to do it this way, imho it is cleaner this way
*** sjc has joined #gnuenterprise
<kilo> reinhard: list properties are... ummm... forgotten?
<reinhard> unfortunately you remember them
<reinhard> so they are not forgotten ;-)
<johannesV> :)
<johannesV> gnue-schema can take multiple files and it processes them in a 'safe' order (regarding to constraints)
<kilo> and will they become true sometime?
<johannesV> but after i'm finished with the memory-leaks i'll look at gnue-schema anyway (maybe i can remove the common-bug regarding gnue-schema)
<reinhard> kilo: i'm not sure
<kilo> that is not good
<reinhard> there is not a practical solution of transporting such a thing over the RPC interface
<btami> bbl
*** btami has quit IRC
<kilo> i remember you always blaming RPC... 8-)
<reinhard> well, OTOH we have implemented stuff in appserver that I've said we won't implement just a week before
<reinhard> more than once
<reinhard> ;-)
<reinhard> let me put it that way
<reinhard> currently it's low priority
<reinhard> lekma's memory leaks are highest priority (johannes is working on that right no)
<reinhard> now
<reinhard> docs are high priority
<reinhard> several forms fixes are high priorit
<reinhard> y
<reinhard> me learning to type is high priority...
<kilo> prerequisit for docs...
*** sjc has quit IRC
<johannesV> hmm
<johannesV> seems as if leaks in appserver are gone ...
<johannesV> but the virtual memory displayed in top still grows (slowly but it grows)
<johannesV> i'll add some gc-checks into rpc-server side then ...
<kilo> isnt it related to the python mem manager?
<kilo> the way it works
<kilo> @monologue
<bigbrother> kilo: Your current monologue is at least 3 lines long.
<johannesV> no
* johannesV back
<johannesV> there were a lot of reference cycles in appserver and common
<johannesV> such cyclic references couldn't be collected by python's gc
<johannesV> like this one: l = []; l.append (l); del l
<johannesV> this code-snipped produces a memory leak
<johannesV> because the object "l" has to references, and after deleting it, one reference is left
<johannesV> so gc cannot collect it, even though "l" is no longer reachable
<johannesV> finding such situations in common and appserver is my current task ...
<johannesV> ok, found another bunch of 105 leaking objects ...
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** kilo has quit IRC
*** feti has left #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> hi everyone
*** jamest has joined #gnuenterprise
<johannesV> hi lekma
<lekma> hi johannesV
<johannesV> i'm still working on the leaks ... :(
<johannesV> but i've removed a lot of them in common and appserver by now
<lekma> :(
<johannesV> so you would have a new version for testing soon ... :)
<lekma> are somme of them coming from the form generation?
<jamest> leaks?
<lekma> johannesV: thx
<johannesV> lekma, no most of them are due to reference cycles in datasource and drivers
<lekma> ok
<johannesV> as well as in appserver ...
<reinhard> johannesV: you could well commit what you have by now
<lekma> i intend today to switch to current svn
<reinhard> so lekma can already test if is is getting better
<johannesV> reinhard, there's a lot of debug-output in there now
<reinhard> ah oh
<lekma> is there something that i should take care of coming from 0.3.1?
<johannesV> i have still about 1680 *missing* objects after the first session get's closed
<johannesV> jamest, yeah, there are a lot of 'unreachable' and 'not freeable' objects
<johannesV> (regarding to garbage collection)
<jamest> really
<johannesV> if we run appserver as daemon and starting the same form again and again appserver is eating memory
<lekma> btw it reminds me: when you close a generated form you don't actually close the session
<johannesV> lekma, this is fixed
<lekma> in 0.3.1
<lekma> oh ok
<johannesV> same applies to 'normal' forms
<jamest> hows it happening
<jamest> some kind of circular reference?
<johannesV> because the closeAll () never get's called in common
<johannesV> jamest, right
<johannesV> like in ResultSet/RecordSet
<reinhard> jamest: common has some really evil circular references
<reinhard> like
<johannesV> where _cachedRecords [] has pointers to RecordSet instances pointing to the resultset
<johannesV> reinhard, i've also solved the ref-probs on Connections ()
<reinhard> yeah what johannesV just says
<reinhard> :)
<johannesV> so common seems to be somehow clean now
<reinhard> cool
<reinhard> hope it didn't break anything
<johannesV> (but i have not tested conditions by now
<johannesV> where all that GObj* descendants have a _parent ...
* johannesV is *hoping* too ....
<reinhard> jamest: another funny circle is resultSet._dataObject._dataSource._currentResultSet
<reinhard> the garbage collection will never free such a construct
<reinhard> because every single member of this circle will keep a reference count of 1
<jamest> blech
<reinhard> unfortunately common is *full* of such circles
<reinhard> because of the ... well ... not entirely clean encapsulation
<reinhard> of the several objects
<jamest> lol
<jamest> that's one way to put it
<reinhard> virtually every object references every other object somehow
<jamest> not entirely clean
<jamest> the goal of the mythical 0.6 release cycle
<johannesV> :)
<reinhard> the funny thing is that there is not a single circle like that in appserver
<reinhard> (johannesV: please speak up if that's not correct ;-))
<reinhard> even though we didn't take special care about that
<johannesV> hmm
<johannesV> at least it seems so for the moment ...
<johannesV> we haven't looked into language-interface very much by now
<jamest> i'd say that appserver has had a bit more design/structure
<jamest> and that common has kinda just grew
<jamest> after all you guys even put in those fancy comment things in appserver
<reinhard> lol
<jamest> but more seriously
<jamest> appserver is the first app to run 24/7 based on common
<reinhard> yes
<reinhard> but report-server would also be
<reinhard> so the problem is not appserver specific
<jamest> so I'm fairly positive we've never looked common running for long periods
<jamest> no, it's definately a common problem
<reinhard> also i can very well envision
<jamest> and the encapsulation thing was sure to bite us in the arse
<jamest> we knew that but was holding off for 0.6
<reinhard> forms running for several days without restarting
<jamest> which, as stated before, is almost like asking for a pacifist in the whitehouse
<jamest> nothing but a dream
<reinhard> a specific form, like order entry or like that
<reinhard> rofl
<jamest> so johannes has already fixed much of this?
* jamest can't imagine that would be an easy cleanup in datasources
<reinhard> frankly, no
<reinhard> he hasn't fixed it
<reinhard> he has introduced some workarounds
<johannesV> :)
<reinhard> that hide the symptoms
<reinhard> so from the user's perspective it looks like fixed
<jamest> sigh
<lekma> lol
<lekma> you mean the it keeps eating memory like a cavern troll eating rocks? :)
<jamest> memory is cheap
<jamest> labor costs aren't
<jamest> so buy more memory
<jamest> problem solved :)
<johannesV> :)
<johannesV> lekma, no it should work better than before, but the *right* solution would be to create a 'clean' model in common
<johannesV> i'm gonna start a regression test with 20000 sessions (including request/fetch/load) ....
<johannesV> i'm curious if it's eating all up ...
<lekma> jamest: and then you change gnue name to java... :)
<jamest> bah
<jamest> not bloody likely
<jamest> :)
<johannesV> ok, seems as if i'm loosing about 1.35 kb per session
<lekma> which is kinda huge improvement
<johannesV> ok, guys ... happy testing :)
<johannesV> please drop me some lines if you find something relevant
<johannesV> wow, after the last changes (in svn) using only request with condition does *not* create a leak
<johannesV> so common seems to fit in quite well now
<reinhard> so the leak is caused by the fetch?
<johannesV> fetch does run *without* leaking now too
<johannesV> checking load () now
<johannesV> it's good looking
<johannesV> *STRIKE*
<johannesV> no more leaks on load () too
<johannesV> so the last changes did it !!!!
<johannesV> please try to do some testing too (especially lekma)
<lekma> johannesV: is it commited??
<johannesV> lekma, yeah
<johannesV> since i've to leave now for a while i'll start another test with 20000 sessions
<lekma> johannesV: generated forms seem to be broken
<lekma> ImportError: cannot import name labels
<lekma> File <gnue_class.gnue_form>, line 8, in form
<lekma> with svn forms and appserver
<reinhard> lekma: you have to re-"gsscvs gnue.gsd"
<lekma> :(
<reinhard> btw
<reinhard> do you make regluar backups meanwhile?
<lekma> reinhard: yep
<lekma> :)
<lekma> but pg backup
<lekma> i didn't yet try to entirely backup with gsdgen
<reinhard> ok
<lekma> what would be command line to bacup everything but the gnue base data??
<reinhard> i would *strongly* recommend backups if you use svn
<reinhard> pg backup is ok
<reinhard> I think
<reinhard> and just in case
<reinhard> I would include gnue base data into the backup
<lekma> but then how can i update with new gnue.gsd
<lekma> ??
<reinhard> ah that's the question
<reinhard> you can just run gsscvs gnue.gsd
<reinhard> over an existing database
<reinhard> it will only change what needs to be changed
<reinhard> and let all the rest of the db untouched
<lekma> ok i'll try that
<reinhard> lekma: of course *after* a backup :)
<lekma> :)
<reinhard> but actually I've even done with *our* real data (hotline) and it worked
<lekma> reinhard: yep it worked
<lekma> johannesV: the memory eating problem seems to be solved with generated forms
<lekma> but not with our xul client
<reinhard> lekma: does your xul client call the close function?
<reinhard> that is *very* important because it frees the memory associated with the session
<lekma> when the session is closed? yes
<reinhard> without close, the session stays open forever (as we have no timeout)
<lekma> or you mean after every request??
<reinhard> no, when the session is closed
<lekma> then yes there a disconnect function that calls Session.close
<reinhard> so it might well be that leaving a session open eats memory
<reinhard> but closing that session an reopening a new one shouldn't eat more memory
<reinhard> however, python doesn't return "freed" memory to the OS
<reinhard> but keeps it for reuse
<lekma> but it works well with generated gnue-forms
<lekma> are there any hints to help me chase circular references in xul generation code
<lekma> ?
<reinhard> johannesV would be able to give you hints
<reinhard> (he is away at the moment, but will be back later)
<reinhard> he played with garbage collection and debugging tools for 2 whole days now :)
<lekma> :)
<reinhard> bbl
*** jcater has joined #gnuenterprise
*** wt has quit IRC
*** sjc has joined #gnuenterprise
<johannesV> lekma, how is that xul-client working ?
<johannesV> it should be enough to call the session-managers close () method with the session-id to be closed
<johannesV> this lead's to a implicit session.logout () which frees the resources
*** lekma has quit IRC
<jamest> johannesV: jcater pointed out that python has a weak reference module as of 2.1
<johannesV> jamest, yes i know
<jamest> as a possible work around
<johannesV> i think if encapsulation is done properly we don't need a workaround :)
<johannesV> anyway, aren't weak-refs a bit dangerous ?
<johannesV> like having a referenced instance beeing already destroyed
<jcater> I don't think so
<jcater> as if you follow the logic
<jcater> if a record set is still being referenced in an app
<jcater> it is being referenced by a result set
<jcater> I personally think weakrefs are the proper solution
*** wendall911 has joined #gnuenterprise
<reinhard> I think weakrefs could be a way to "break" circular references
<johannesV> hmm, i've thought about weakrefs too, but didn't follow that path in very much detail
<reinhard> however explicitly breaking the circle like johannesV did works, too
<johannesV> as i've said, better would be a 'good' design ...
* jcater missed that conversation
<johannesV> :)
<jcater> johannesV: ?
<jamest> jcater: our love for
<jamest> object._this._is._so._wrong
<johannesV> jcater, i mean, building classes which avoid circular refs by design
<johannesV> or at least reduce to a minimum
<jcater> that's easy to say, of course
<johannesV> jcater, yeah, i know
<johannesV> :)
<reinhard> jcater: we are not trying to offend you
<johannesV> it's easy to say after the whole stuff has grown for years ... and the one looks at it
<reinhard> please don't get us wrong
<jcater> reinhard: no, not offended
<jamest>  /msg jcater i think they are just trying to find a way to sneak comments into the code during "updating" the code base
<johannesV> but the great thing was the work all you guys have put in there before ...
<johannesV> *lol*
<johannesV> yeah, i love to insert comments ... :)
<jcater> just remember though
<jcater> the datasources you see
<jcater> are a reimplimentation
<jcater> based on lessons learned from the first time
<jcater> not to say there isn't room for improvements, of course
<jcater> :)
<reinhard> :)
<johannesV> :)
<jcater> but this is clearly all derek's fault
<reinhard> I'd say there are several "levels" of object encapsulation
<jamest> :p <- just to be different
<reinhard> you can take it very "strict" (nearly kinda religious) like I do
<reinhard> (and I force johannesV to do) ;-)
<reinhard> or you can be more flexible
* johannesV hasn't to be forced to
<reinhard> the flexible way gives you the power to very quickly implement stuff that wasn't originally planned
<jamest> one thing about the cleanup/redesign or whatever
<reinhard> as you can do any thing at any place and have access to everything you need from everywhere
<jamest> you're not talking about going completely to accessor functions are you?
<jamest> getSomething()
<jamest> setSomething()
<reinhard> however, I had to learn that the strict way can save you some headaches when it comes to details
<reinhard> jamest: no
<reinhard> jamest: good example
<reinhard> (I hope at least)
<reinhard> is in dbdrivers
<reinhard> the RecordSet and ResultSet calls back into the datasource layer
<reinhard> to execute some triggers at the correct point of time
<reinhard> in a "religious" object hierarchy, RecordSet and ResultSet would be a layer *below* GDataSource
<reinhard> so GDataSource would use and call RecordSet and ResultSet objects
<reinhard> but RecordSet and ResultSet would not even know about GDataSource and it's properties and functions
<johannesV> ok, have to leave now, but i'll read the logs tomorrow morning
<johannesV> good night all
*** johannesV has quit IRC
<jcater> but using that model, wouldn't GDataSource have to handle all database inserts, updates, etc?
<jcater> at least, given what the resultsets and recordsets actually call back to datasource to look at
<chillywilly> gah...have a headache
<reinhard> jcater: isn't there a GDataSource.commit (or post or whatever) anyway?
* reinhard doesn't know offhand
<reinhard> but as I said it's a good example
<reinhard> even for my statement that such a model is much harder to implement
<reinhard> at the start
<reinhard> actually I wouldn't even go so far to say that the one model is "better" or "worse" than the other
<jcater> no, neither would I
<jcater> my only thing is I'm not an OO person just for the sake of being OO
<jcater> (which is one reason I love python)
<jcater> but I will admit datasources have far too many cross-references now
<reinhard> just you are tempted to bitch at the model you don't usually use when you stumble over the disadvantages of it :)
<reinhard> it#
<reinhard> it's not even OO actually (IMHO)
<reinhard> it's more a matter of thinking in layers
<jamest> how would those lower level objects call up through the tree
<jamest> as I seem to recall that we had to do some of that to get stuff working that wasn't originally planned
<jcater> I don't want to sacrifice the abstraction we have now
<jcater> between resultsets and recordsets and dataobjects
<jcater> (abstractions from end developers, not internal ones)
<jcater> and I fear by trying to eliminate the circular references
<jcater> (which I've always disliked too, but see as necessary evil)
<jcater> that everything would have to be done through dataobjects then
<jcater> well, it could definitely use cleanup
<reinhard> please again don't get me wrong
<jcater> part of the problems come from the fact that
<jcater> no less than 18 months ago
<jcater> there was no GConnection class
<reinhard> I am *not* trying to talk you into *any* structural change of common
<jcater> and stuff was split up after the fact
<jcater> by the same token, some of the circ references came from us adding support
<jcater> for automatic master-detail relationships, iirc
<jcater> but not all, of course
<jamest> reinhard: you were talking about trying to leave the external interface intact but trying to leave the common level API about the same right?
<reinhard> actually, we just had those memory leaks and they were holding back lekma
<jamest> so that we could still treat resultsets as lists and recordsets as dicts?
<reinhard> and we promised him to fix anything that holds him back
<reinhard> I was not talking about changing anything, really
<reinhard> I was more philosophing about different approaches
<jamest> reinhard: fwiw I don't think anyone is against changes
<reinhard> actually I am
<reinhard> as common in general and datasources especially
<reinhard> work pretty well the way you did it
<reinhard> and I would *happily* let you do the *minor* changes that we need now
<reinhard> for the slightly different aspects that appserver brings into the game
<reinhard> (as for example running as a daemon)
<reinhard> it's just to same old problem of having to do changes in code that is structured with different strategy than you usually do
<reinhard> I *bet* you would have the same problems if you had to make changes in appserver
<reinhard> brb
<jcater> well, bottom line
<jcater> if it doesn't break *my* code, I don't care
<jcater> :-)
* dneighbo goes and breathes on jcater's code
<dneighbo> its broke now fewl!
<dneighbo> curse de la masta
<reinhard> back
<reinhard> bbl
*** Pe941 has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** Pe941 has quit IRC
*** holycow has joined #gnuenterprise
*** kilo has quit IRC
*** kilo_ has joined #gnuenterprise
<reinhard> night all
*** reinhard has quit IRC
*** kilo_ has quit IRC
*** jamest has quit IRC
*** involved has joined #gnuenterprise
<involved> hi
<involved> how can i get the "ERP Packages"? are they downloadable?
<involved> anyone there?
*** involved has quit IRC
*** involved has joined #gnuenterprise
*** involved has quit IRC
*** involved has joined #gnuenterprise
<involved> back for good.. damn connection.
*** jamest has joined #gnuenterprise
*** wendall911 has quit IRC
<chillywilly> bah
<chillywilly> involved: there are no packages, only tools right now
*** wendall911 has joined #gnuenterprise
*** holycow has quit IRC
*** sjc has quit IRC
<involved> this is damn confusing..
<involved> but i got the login screen for the sample ;)
<involved> c u
<involved> away*
*** holycow has joined #gnuenterprise
*** wendall911 has quit IRC
*** holycow has quit IRC
*** jcater has quit IRC
*** jamest has left #gnuenterprise
*** jcater has joined #gnuenterprise