*** holycow has joined #gnuenterprise
*** SachaZzz has quit IRC
*** reinhard has joined #gnuenterprise
*** titopbs has quit IRC
*** holycow has quit IRC
*** dimas has quit IRC
*** dimas has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<dimas> good morning
<reinhard> good morning all
<dimas> hi reinhard
<ajmitch> good morning
<ajmitch> ;)
<ajmitch> reinhard: you actually slept?
<reinhard> sure
<reinhard> about 6 hours
*** sjc has joined #gnuenterprise
*** mnemoc has quit IRC
*** mnemoc has joined #gnuenterprise
*** btami has joined #gnuenterprise
<johannesV> reinhard, DBSIG2/DataObject.py has still an 'old'-style header
<reinhard> right
<reinhard> that file will die a long death today
<johannesV> but it's great to see how everything's getting smaller :)
<johannesV> ah, ok :)
<johannesV> i had a hard time yesterday doing that _parent-rework in designer :(
<reinhard> ouch
<johannesV> but i think it's finished ... i'll change ParserObj._parent to __parent now and change it into a weakref ...
<reinhard> ok great
<reinhard> i'm curious if our memory leaks go away then :)
<johannesV> this way all accesses to _parent (which i've forgotten) should give an AttributeError anyway
<johannesV> reinhard, i'm not sure about that :)
<johannesV> but at least it will get a lot easier to catch, and a lot harder to create new ones :)
<johannesV> anyway ... i've got some other work to do first :)
<reinhard> ok, but then could you commit the changes for _parent you made so far?
<johannesV> of course
*** Amorphous has quit IRC
*** Amorphous has joined #gnuenterprise
*** rynik has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** dimas has quit IRC
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** dimas has joined #gnuenterprise
<kilo> who can stop reinhard?
<dimas> does he do something ugly? :)
<johannesV> ok, here we go ...
<reinhard> *yes!*
<reinhard> just fixed my first memory leak
<reinhard> :)
<kilo> your mem leak or some software mem leak?
<johannesV> great ... there are quite many of them again
<reinhard> johannesV: no, AFAICT it was a single one
*** sjc has quit IRC
<johannesV> ah, well, try a generated form ...
<reinhard> appserver seems to be clean again
<reinhard> ah
<reinhard> good idea :)
*** StarDeep has joined #gnuenterprise
<reinhard> johannesV: you going to remove all those deprecated unlink calls?
<johannesV> oh, sorry ..
<johannesV> forgotton about that ...
<reinhard> no problem
<reinhard> just wanted to know wheter you gonna do it
<johannesV> yeah ... on my way ...
<johannesV> ok, they should have gone now ...
<reinhard> thanks
<reinhard> did you test with generated form?
<reinhard> BTW I would seriously like to see the GC debugging moved to GBaseApp and bound to something like --debug-gc
<reinhard> and I wonder whether it would be possible to show the circles somehow
*** StarDeep has left #gnuenterprise
*** StarDeep has joined #gnuenterprise
*** btami has quit IRC
<rynik> Hi all.
<rynik> I've been playing around with gnue a little
<rynik> and it seems a got the appserver running allright
<rynik> with a initialized db-backend.
<rynik> Were should I look next?
<rynik> Is there a General ledger runable with a form to insert
<rynik> new records?
<reinhard> rynik: if you are looking for a turnkey application
<reinhard> we have to say we're not yet there
<reinhard> we have some samples and unifinished applications in svn
<rynik> I'm NOT looking for a turnkey app! A'm asking to learn where work HAS been done
<reinhard> ah ok
<reinhard> cool :)
<reinhard> did you have a look at the developer's guide?
<rynik> I must say I browsed it very quickly
<reinhard> ah ok
<reinhard> you can download some package stuff from
<rynik> Were are you working now then?
<reinhard> $ svn co svn://svn.gnuenterprise.org/var/svn/gnue/trunk/gnue-packages gnue
<reinhard> and some more from
<reinhard> $ svn co svn://svn.gnuenterprise.org/var/svn/gnue-contrib/trunk gnue-contrib
<reinhard> and
<reinhard> $ svn co svn://svn.gnuenterprise.org/var/svn/gnue-luca/trunk gnue-luca
<reinhard> gnue-packages is an ongoing attempt to create the "official" packages for gnue
<reinhard> gnue-luca aims at a more small business oriented solution
<reinhard> and gnue-contrib is just a collection of some stuff people once did with gnue and wanted to have it archived so others can look up things and see how they did it
<rynik> Thanks, I'll have a look in gnue-luca.
<johannesV> reinhard, there's a module called 'Cyclops.py' which can show reference cycles ... but it's not a standard module and it's usage is very different from the gc-debugging
<johannesV> is appserver still clean now, or do you have leaks still there ?
<reinhard> AFAICT there are no leaks
<reinhard> but you wanted to try generated form
<reinhard> as to finding the cycles
<reinhard> I think we could find them ourselves by recursively iterating through the __dict__ of the objects we find and through the dicts and the lists
*** tiredbones has joined #gnuenterprise
<johannesV> reinhard, regarding cursor-description ... what kind of information are you interested in ?
<reinhard> field names
<johannesV> 'if there are fieldnames', or the field names themselfs
*** faqroo has quit IRC
<johannesV> :)
<johannesV> reinhard, now i have a unittest-script to answer your questions ...
<reinhard> in case there are field names, whether they are in unicode or 8-bit-strings
*** jamest has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** jamest has joined #gnuenterprise
*** kilo has left #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> hi
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** lekma has quit IRC
*** lekma has joined #gnuenterprise
*** aries_mindworks has joined #gnuenterprise
<aries_mindworks> hi
<aries_mindworks> I try to promote GNUe in our learning programs
<aries_mindworks> http://aries.mindworks.hu/node/55
<aries_mindworks> For the system programmer students, I've set the thesis subjects based on GNUe
<aries_mindworks> I hope it will incressare the usability of GNUe...
<jamest> cool
*** btami has joined #gnuenterprise
<btami> hmm, seems designer is broken
<btami> DB000:    File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/designer/forms/Instance.py", line 93, in __init__
<btami> DB000:     BaseInstance.__init__(self, app, *args, **params)
<btami> DB000:    File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/designer/base/Instance.py", line 225, in __init__
<btami> DB000:     self._app.mru.addMenu(self.menubar.getMenu('File|Open Recent|'), self)
<btami> DB000:    File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/designer/base/MRUManager.py", line 118, in addMenu
<btami> DB000:     self.refreshMenu(menu)
<btami> DB000:    File "/media/disk-hda6/home/tamas/svn/gnue/.cvsdevelbase/gnue/designer/base/MRUManager.py", line 158, in refreshMenu
<btami> DB000:     wx.EVT_MENU(menu.__instance, tid, self._app.OnOpenRecent)
<btami> DB000:    File "/usr/lib/python2.3/site-packages/wxPython/wx.py", line 1368, in EVT_MENU
<btami> DB000:     win.Connect(id, -1, wxEVT_COMMAND_MENU_SELECTED, func)
<btami> DB000:  AttributeError: Instance instance has no attribute 'Connect'
<btami> t
<btami> got it with: gfdes ntro.gfd
<btami> s/ntro/intro
<johannesV_> which intro.gfd
<btami> from form samples
<btami> same with any other form too
*** titopbs has joined #gnuenterprise
*** jamest has left #gnuenterprise
<aries_mindworks> btami: Szia!
<aries_mindworks> btami: a Mindworks-nél oktatunk is, a rendszerprogramozó nebulóknak szakdolgozattémát gnue-ben jelöltem ki
<aries_mindworks> btami: remélem sikerül vele egy kis lökést adni a fejlesztésnek. bár a nebulók inkább
<aries_mindworks> btami: kezdők még mindenben nagyon...
*** jamest has joined #gnuenterprise
<johannesV_> btami, that error is really strange ... as i cannot find what it has got to do with the latest changes ...
<johannesV_> what does wx.EVT_MENU does ?
<btami> aries_mindworks: cool
<aries_mindworks> btami: http://aries.mindworks.hu/node/55
<btami> johannesV_: as i know it binds an event to a menu entry
<johannesV_> yeah, ok, but what about it's arguments ...
<johannesV_> is there any documentation about wx available out there ?
<reinhard> jamest: 2 questions:
<reinhard> 1. after calling all those _beforeCommitInsert etc. triggers, the RecordSet checks if the status has changed and if yes, calls the triggers again
<reinhard> I wonder how the status could change in such a trigger
<reinhard> and
<btami> johannesV_: wxwin2.4-doc
<reinhard> 2. ResultSet.isRecordPending seems to be used nowhere; do you use it somehow in your non gnue common-based apps?
<johannesV_> btami, thanks .... but i really dislike fixing designer
<jamest> reinhard: #2, i don't use it
<aries_mindworks> bye
*** aries_mindworks has left #gnuenterprise
<jamest> #1 not sure
<jcater> I remember having to add that
<jamest> would it be possible for a record to delete itself via the trigger
<btami> johannesV_: me too :)))
<jamest> but even so that would mean the insert trigger shouldnt need to fire
*** photon_ has joined #gnuenterprise
*** photon_ has left #gnuenterprise
*** titopbs has quit IRC
<johannesV_> btami, i'm unable to find out something about arguments of wx.EVT_MENU ...
<btami> strage
<jamest> johannesV_: where are you looking?
<btami> the latest commit does nearly nothing, just comments and only one new line added
<jamest> unfortunately sometimes you have to read the wxpython source
<johannesV_> i've downloaded that wx2.4-doc pacakges
<johannesV_> and googled a bit
<btami> so something changed in another place (not in MRUManager.py)
<jamest> what you trying to do?
<johannesV_> well, on adding a file into the mru of designer it throws an exception
<johannesV_> it's the line where wx.EVT_MENU get's called
<jamest> when did that start?
<johannesV_> i don't know
<johannesV_> btami, do you know when this started ?
<johannesV_> it happens on loading a gfd into designer, or starting with a gfd from the commandline
<btami> johannesV_: dunno
<johannesV_> ah, so i'm not the one who broke this ... :)
<johannesV_> to me it looks like binding the event 'open the given gfd file' to the mru-menu-item fails, cause EVT_MENU get some kind of wrong arguments (at least in type)
<johannesV_> DB000:    File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/designer/base/MRUManager.py", line 158, in refreshMenu
<johannesV_> DB000:     wx.EVT_MENU(menu.__instance, tid, self._app.OnOpenRecent)
<johannesV_> DB000:    File "/usr/lib/python2.3/site-packages/wxPython/wx.py", line 1368, in EVT_MENU
<johannesV_> DB000:     win.Connect(id, -1, wxEVT_COMMAND_MENU_SELECTED, func)
<johannesV_> DB000:  AttributeError: Instance instance has no attribute 'Connect'
<johannesV_> that's the tail of the traceback
<johannesV_> btw., that Instance instance is of type gnue.designer.forms.Instance.Instance, which really has no Connect method
<johannesV_> if i change MRUManager.py  to come along without a traceback, and finally try to close designer i get another exception:
<johannesV_>  File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/designer/Designer.py", line 308, in OnExit
<johannesV_> DB000:     instance.Close()
<johannesV_> DB000:  AttributeError: Instance instance has no attribute 'Close'
<johannesV_> which is also true, since forms/Instance.py has wether a Close () method nor a Connect () method
<jamest> that's odd as I was in there 2 weeks ago and don't recall seeing that
<jamest> just a minute, i need to reboot
*** jamest has left #gnuenterprise
*** StarDeep has quit IRC
<johannesV_> hmm, maybe it was really me who broke something
<btami> oh no !
<btami> it was derek :)
<jcater> the pre-* triggers can change the state of the record
<jcater> but post-* triggers shouldn't
<jcater> so I think that's why you have to recheck the state after a trigger is run
<jcater> it's been a while
<reinhard> jcater: right
<johannesV_> ah, i've just updated svn to the version before my changes, and it raises the same error ... so it must have been derek
<reinhard> the trigger code can delete a record
<jcater> right that it's been a while?
<jcater> or right about what I said? :)
<reinhard> about 2 years
<reinhard> both right :)
*** jamest has joined #gnuenterprise
<reinhard> jamest and jcater: very stupid question now
<reinhard> regarding the order of function definitions
<reinhard> do you prefer the official main functions of an object at the top and the internal helper functions at the bottom of the file
<reinhard> or other way around?
<reinhard> e.g. if an object defines a foo(self) that is meant to be used
<jamest> i don't have a preference
<reinhard> and that foo(self) internally uses __bar(self) as a helper
<jamest> internally i've started grouping them by function
<jamest> so my external methods and private support methods are in the same sections
<jamest>   #===========
<jamest>  # Tax Function
<jamest> # =================
<jamest> def pub
<jamest> def pub
<jamest> def _priv
<jamest> # ==============
<jamest> # Output Fucntion
<jamest> # =============
<jamest> pub
<jamest> pub
<jamest> priv
<jamest> etc
<jamest> but that's just me :)
<johannesV_> bbl
<reinhard> jamest: that makes sense
<reinhard> and you put pub before priv
<reinhard> I've always done it the other way around
<jamest> that's only recently
<reinhard> and I consider changing that
<reinhard> as I found out I like the most important things of a file being at the top of the file
<reinhard> rather than the bottom
<jamest> yeah, i find i change the pub more than the priv
<jamest> so started doing it that way
<jamest> but like i said, i'm not that picky
<reinhard> I did not assume that ;-)
<reinhard> but trying to find out what makes more sense
<btami> bbl
*** btami has quit IRC
<jamest> and you ask jcater and me?
<reinhard> sure :)
<jcater> I'm in the habit of what you described, reinhard
<jcater> public at top
<jcater> private at bottom
<jcater> just a matter of habit, though
<jcater> I don't care
*** johannesV_ has quit IRC
<reinhard> ok thanks for your input j*
<reinhard> i've been thinking about next gnue-common release
<jamest> i'm sorry
<reinhard> huh?
<reinhard> you're sorry about what?
<jamest> [10:44:20] <reinhard>i've been thinking about next gnue-common release
<reinhard> you're sorry when I think about a release?
<jamest> :)
<jamest> that you have to
<reinhard> oh
<reinhard> lol
<reinhard> however
<jamest> are we that close
<jamest> considering the changes in datasources
<reinhard> *what* i'm actaully thinking about
<reinhard> no we are not close
<reinhard> that's the point (of part of it)
<reinhard> considering that there was quite some restructuring in datasources
<reinhard> and i've also removed deprecated stuff that has been deprecated for > 1.5 years or so
<reinhard> and a major cleanup
<reinhard> i've been thinking whether this would justify a 0.6
<reinhard> of common
<reinhard> or would you prefer to keep at least the first 2 digits in sync between common, forms, and designer?
<jamest> no need to keep in sync
<reinhard> and how would 0.6 as the next release match your release plan?
<reinhard> (hope the word "plan" doesn't make you laugh) ;-)
<jamest> :)
<reinhard> FWIW it will still take some time
<reinhard> this cleaning  up *really* takes time
<reinhard> did actually underestimate it I think
<jamest> cleanup was the goal for the 0.6 series iirc
<jamest> and was going to be that entire series
<jamest> as its a big job :)
<reinhard> and I am thinking about something like 0.5.90/91/92 or 0.5.99-beta1/2/3 or so
<jamest> so a 0.6.0 release that is major cleanup makes sense
<jamest> probably also a good series to decide how we want common to evolve
<jamest> a single library, or sub module packages that install in comon
<reinhard> another question that just arises
<reinhard> are SQL datasources (as opposed to "object" datasources) read only or can they be properly updated?
<jamest> read only iirc
<reinhard> lol
<reinhard>   def createEmptyResultSet(self, readOnly=0, masterRecordSet=None):
<reinhard> what reason could somebody have to create a read only empty result set?
<reinhard> you can't really do much with such a thing :)
<jamest> wouldn't the master still be able to update it to reflect detail info?
<reinhard> an empty result set wouldn't even have a single record
<reinhard> you couldn't even insert an empty record
<reinhard> gerp told me that this parameter is actually never used :)
<reinhard> grep
<jamest> you do that w/ grep?
<reinhard> yep
<jamest> does grep do recursive dir searches?
<reinhard> find . -name "*.py" | xargs grep "foo"
<jamest> you should try glimpse
<reinhard> as we talk of read only
<jamest> http://webglimpse.net/download.php#bins
<jamest> much faster after indexing the gnue tree
<reinhard> would we at some point want to support partially read only resultsets?
<reinhard> stuff like
<reinhard> primary key of a table is read-write for inserts and read-only for existing records
<reinhard> or
<reinhard> select foo, bar, someformula(x) from table
<reinhard> and foo, bar would be updateable
<reinhard> actually i can answer that question myself
<reinhard> we do want that
<reinhard> at least for appserver's calculated fields
<jamest> well then, that's settled
<jamest> :)
*** sjc has joined #gnuenterprise
<jcater> reinhard, fields support that setting in forms
<jcater> i.e., editable only on new records
<reinhard> ah
*** dimas has quit IRC
<jamest> thought that was at the block level in forms
*** wendall911 has joined #gnuenterprise
<jcater> field.editable can be Y, N, new, or update
<jcater> new == new records only
<jcater> update == updates only
<jcater> I think blocks have the same editable attribute
<jcater> ooo
<jcater> and fields have one additional option
<jcater> editable=null
<jcater> i.e., only if the field is currently empty
<jcater> (regardless of new or updated record)
<reinhard> nifty
<reinhard> actually
<reinhard> looking at things very closely
<reinhard> the whole read only vs. read/write thing really happens at block and field level
<reinhard> and all those read only exceptions at ResultSet and RecordSet level never happen at all
<reinhard> because AFAICT there is one single call to createResultSet with readOnly set at all
<reinhard> and that one call is in reports
<reinhard> so after staring at the screen for about one hour I end up with asking myself whether this complete read only handling in RecordSet/ResultSet could be completely removed??
<reinhard> or is there any secret plan behind it that I don't see now?
<reinhard> or do you use it in your common based non-gnue apps?
<jcater> reinhard, the point of that was for future needs
<jcater> mainly caching
<jcater> and master/detail records
<jcater> running reports against a 10,000 record table will chew up memory
<jcater> my plan was to use that readOnly flag that only reports passes in
<jcater> to eliminate a lot of the master/detail caching, as there was no need for it
<jcater> so, yes, there's no/not much code to back that up
<jcater> but that's why it was there
<jcater> if you have a different solution, that's fine too
<jcater> did that make sense?
<reinhard> ah
<reinhard> so that read only attribute is more of an "info" than a "restriction"?
<reinhard> would you see any use in the dbdriver being able to "override" the editable flags given in the gfd?
<reinhard> e.g. making a block read only if it is connected to a db driver that can't write (like static or some file-based)
<reinhard> nevermind
<reinhard> I'll just leave that as it is
<ajmitch> hi all
<reinhard> hi ajmitch
<ajmitch> you've forced me to have to do the init script & all for appserver :)
<ajmitch> otherwise I'll have to make /var/run/gnue world-writeable (which isn't so bad)
<reinhard> oh
<reinhard> that wasn't me
<reinhard> who filed the bug
<reinhard> :)
<ajmitch> no, but  it was you & johannesV who are the evil gnue hackers ;)
<rynik> I filed the bug
<rynik> reinhard: I try to run your luca apps but I get a login to appserver form asking for Company: and Fiscal year: . What is that?
<reinhard> there is some sample data that you might want to import
<rynik> Is'nt that done just by putting it in the module path?
<rynik> And do a HUP..
<reinhard> I mean the gsd
<reinhard> sample.gsd
<reinhard> you can import it with gnue-schema
<rynik> right I'll do that,thanks
<reinhard> err
<reinhard> demo.gsd
<rynik> OK
<reinhard> then you have a sample company named demoa
<rynik> ????
<reinhard> company and fiscal year is asked at the startup of gnue
<reinhard> it defines the subset of data you want to work with
<reinhard> usually for multi company able programs there's a complete set of data per company
<rynik> 'demoa' is not a valid filter....
<reinhard> you did import the demo.gsd?
<rynik> I'did
<rynik> There might be some problem with encoding in the db
<rynik> I can't lock directly into it with psql
<rynik> gnue=# \d
<rynik> FEL:  invalid byte sequence for encoding "UNICODE": 0xe47273
<reinhard> yuck
<rynik> Did I create the db in unicode and put iso in it?
<reinhard> not sure
<reinhard> usually postgres handles that quite safely
<rynik> I'll look into gnue-setupdb and see whats going on then.
*** jcater has quit IRC
<rynik> Is the gnue db supposed to be in unicode?
<reinhard> usually yes
*** SachaS has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
<rynik> It seemsPostgreSQL has problems with gnue.gsd and that has to do with wich locale the database cluster was initiated with. I use sv_SE.  The damn thing (postgresql) stumbles on its own translations as I understand it.
*** jamest has left #gnuenterprise
<reinhard> good night all
*** reinhard has quit IRC
*** wendall911 has quit IRC
*** jcater has joined #gnuenterprise
*** sjc has quit IRC
*** jcater has quit IRC
*** titopbs has quit IRC
*** jamest has joined #gnuenterprise
*** tiredbones has quit IRC
*** jcater has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** csingley has joined #gnuenterprise
*** csingley has quit IRC
*** jamest has quit IRC
*** jcater has quit IRC
*** titopbs has quit IRC