*** tiredbones has joined #gnuenterprise
*** dimas has joined #gnuenterprise
*** dimas has quit IRC
*** dcmwai has quit IRC
*** reinhard has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** chillywilly has quit IRC
*** chillywi1ly has joined #gnuenterprise
*** reinhard has quit IRC
<kilo> good morning
*** dimas has joined #gnuenterprise
*** btami has quit IRC
*** btami has joined #gnuenterprise
*** mnemoc has quit IRC
*** btami has quit IRC
*** mnemoc has joined #gnuenterprise
*** holycow has quit IRC
*** jamest_ has joined #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> hi all
<ajmitch> hi
*** sjc has quit IRC
*** kilo has quit IRC
*** SachaS has joined #gnuenterprise
<mnemoc> hi, can i create 'create-only' forms?
*** SachaS has quit IRC
*** reinhard has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** wendall911 has joined #gnuenterprise
*** jcater has joined #gnuenterprise
<mnemoc> hi, can i create 'create-only' forms? and, does gnue-* run inside ddd?
<reinhard> mnemoc: I would not know how to do a "create-only" form
<reinhard> what is ddd?
<nickr> debugger
<nickr> a frontend to gdb
*** tiredbones has quit IRC
*** reinhard has quit IRC
*** reinhard has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** titopbs has quit IRC
<jamest_> nickr: in designer
<jamest_> set the blocks allow delete to false
<jamest_> then set the allow editing to new records only
<jamest_> i *think* this will have the desired effect
<jamest_> we support python's built in debugger via
<jamest_> --interactive-debugger
<jamest_> with any gnue app
<jamest_> whoops, that first part was for mnemoc
*** lekma has quit IRC
*** lekma has joined #gnuenterprise
*** tiredbones has joined #gnuenterprise
<tiredbones> for the log: In doc "GNUe Forms: A Developer's Intro." page 7, section titled "Creating the Datasource",second paragraph has- Edit | Insert | Datasource, Should read Insert | Datasource.
<tiredbones> Is anyone on the list using the current release of gnue-designer?
<reinhard> not me
<tiredbones> How do you design your forms?
<reinhard> vi
<tiredbones> Do you have some docs that one could use for that method?
<reinhard> not really
<reinhard> when I need something I either try to find a sample that does the same or look in the code
<jamest_> tiredbones: you have to know to gfd format
<jamest_> which is only really documented well in GFParser.py :(
<reinhard> (I understand that's not an option for you= :)
<jamest_> what I do is use designer wizard to rough out the form
<jamest_> use vi or kate to add trigger logic (or merge multiple forms into a single tabbed one)
<jamest_> then all layout changes I do in designer
<jamest_> gives me the quickest results
<jamest_> plus doing it that way you'll get to understand the gfd format
<tiredbones> I was going to create a small system to learn all the part, but I guess I got to do it differently. Is there anyone working on gne-designer, seeing how that's first piece of software most people are going to come into contact with/
*** siesel has joined #gnuenterprise
<tiredbones> Should I keep going thru this document and pick-up the errors or forget it?
<jamest_> tiredbones: i'd appreciate the bug reports
<jamest_> i'll fix the one you listed above now
<tiredbones> Hold off, there 's more. I'll put them in the log here.
<jamest_> too late :)
<jamest_> actually, the commit failed
<reinhard> hmmm... reminds me that I've promised to fix po file regeneration...
*** btami has joined #gnuenterprise
<btami> hi
<reinhard> hi btami
<btami> <jamest_> which is only really documented well in GFParser.py :(
<btami> hi reinhard
<btami> just for record
<btami> kilo updatedthe form's dev guide
<btami> from GFParser.py with many description
<jamest_> cool
<kilo> yes i am 8-)))
*** sjc has joined #gnuenterprise
<tiredbones> btami, do you know the name of the guide? I did a svn yesterday and didn't see any change in the "GNUe Forms: A Developer's Introduction".
<btami> Developers-Guide.sxw
<btami> reinhard: got an error with gnue-invoice
<btami> Traceback (most recent call last):
<btami>    File "<unknown_executioncontext>", line 9, in blkItem_fldQuantity_POST_CHANGE_onchange
<btami>    File "c:\python23\Lib\site-packages\gnue\common\logic\NamespaceCore.py", line 315, in __call__
<btami>     return self._objectFunction(*args)
<btami>    File "c:\python23\Lib\site-packages\gnue\forms\GFObjects\GFBlock.py", line 714, in callFunction
<btami>     parameters)
<btami>    File "c:\python23\Lib\site-packages\gnue\common\datasources\GDataSource.py", line 180, in callFuncOfCurrentRecordsetEntry
<btami>     return rset.callFunc(name,params)
<btami>    File "c:\python23\Lib\site-packages\gnue\common\d
<btami> grrr, too long
<btami>    File "c:\python23\Lib\site-packages\gnue\common\rpc\drivers\xmlrpc\pw_xmlrpc\ClientAdapter.py", line 95, in _runMethod
<btami>     result = to_call (*__args, **params)
<btami>    File "c:\python23\lib\xmlrpclib.py", line 1032, in __call__
<btami>     return self.__send(self.__name, args)
<btami>    File "c:\python23\lib\xmlrpclib.py", line 1319, in __request
<btami>     verbose=self.__verbose
<btami>    File "c:\python23\lib\xmlrpclib.py", line 1083, in request
<btami>     return self._parse_response(h.getfile(), sock)
<btami>    File "c:\python23\lib\xmlrpclib.py", line 1217, in _parse_response
<btami>     p.feed(response)
<btami>    File "c:\python23\lib\xm
<btami> the last 3 line is
<btami>    File "c:\python23\lib\xmlrpclib.py", line 816, in end_double
<btami>     self.append(float(data))
<btami>  ValueError: invalid literal for float(): 138,75
<reinhard> client and server on same machine?
<btami> yes
<btami> it worked before your last few changes
<reinhard> the comma strikes me odd
<reinhard> is 138.75 a number you entered in a form, a number returned from the database, or anything completely different?
<btami> i think it's a calculated value,itemprice=111.0 (from db) and i press 1 as quantity
<btami> maybe net+vat ?
*** titopbs has joined #gnuenterprise
<reinhard> do you use the comma as decimal point in hungary?
<reinhard> IOW
<btami> yes
<reinhard> could you test if it still happens when you run server and client in the C locale?
<btami> trying...
<btami> bingo!
<btami> it's ok with C locale
<tiredbones> clear
<tiredbones> soory
<reinhard> tiredbones: no, I won't go away ;-)
<tiredbones> I hope not!
<reinhard> btami: now the question is what on earth converts the number to a string using the locale...
<btami> i don't know,but it worked some days before...
<btami> maybe your fixes forlekma
<btami> grrr, my space isdead
<btami> :)
<kilo> alt+032
<reinhard> btami: thatsannoyingisntit?
<btami> sigh
<reinhard> btami: I wouldn't know which change could cause this
<reinhard> the error occures client side, right?
<btami> yes
<reinhard> and the return type of the calculated field is number, right?
<btami> yes
<reinhard> hmmm
<reinhard> just noticed that the result of a calculated field seems to not get type-checked
<reinhard> in geasInstance.py, line 364
<reinhard> if you add a "print repr(result)" before that return
<reinhard> do you see any 138.75 there?
<reinhard> with . or with ,
<btami> 138,75 three times
<btami> not, fives times:)
<reinhard> in quotes? with dot or with comma?
<btami> just 138,75
<reinhard> hmmm
<btami> i got this:
<btami> BILLING_Head::OnInit - dateIssued set to 2005-02-16 00:00:00,00
<btami> BILLING_Head::OnInit - Seller is BÉRADÓ'88 KFT.
<btami> None
<btami> 0
<btami> 0
<btami> 0
<btami> ''
<btami> 111.0
<btami> 111.0
<btami> 111.0
<btami> 111.0
<btami> 138,75
<btami> 138,75
<btami> 111.0
<btami> 138,75
<btami> 138,75
<btami> 138,75
<btami> 111.0
<btami> 27,75
<btami> 27,75
<btami> 111.0
<btami> 27,75
<btami> 27,75
<btami> 27,75
<btami> u'Vev\u0151 1'
<btami> the values like 111.0 are coming from db
<btami> the values like 138,75 are calculated
<reinhard> no matter what I do, I can't get python to print numbers with a comma instead of a dot
<reinhard> can you also output what type the values are of?
<reinhard> bbl
<btami> 111.0
<btami> <type 'float'>
<btami> 138,75
<btami> <type 'float'>
<reinhard> that is insane
<reinhard> I don't get it
<btami> reinhard: i can reboot to linux to test it, if it helps
<reinhard> btami: that is on windows?
<reinhard> oh
<reinhard> might be interesting, yes
<reinhard> bbl in a few minutes
<btami> ok
*** btami has quit IRC
<tiredbones> ls
<lekma> :)
*** btami has joined #gnuenterprise
<reinhard> back
<reinhard> lekma: btw, any further multithreading experiments?
<lekma> yes
<lekma> some
<reinhard> and some interesting results?
<lekma> i still have the same pb we already talk
<lekma> now i'm trying
<lekma> to thread
<ajmitch> morning
<lekma> rpc calls
<lekma> a server side
<reinhard> lekma: did you try to find out who closes the connection?
<lekma> no not yet
<reinhard> ok
<reinhard> good morning ajmitch
<lekma> where do you think i should put prints to find out
<lekma> brb
<reinhard> lekma: there are two lines in geasList.py
<reinhard> where "self.__recordset = None" is executed
<reinhard> as one of your tracebacks explicitly complained about self.__recordset being none, one of these lines must get executed
<reinhard> very shortly *before* the traceback
<reinhard> (well, of course before the traceback, silly me....)
<btami> reinhard: it's ok on linux, no 138,75 at all
<btami> sigh
<btami> so it's a win related bug oly
<btami> s/oly/only
<btami> good night all
*** btami has quit IRC
<tiredbones> I'm saving all these errors, oly and the like, for the jargon file.
<reinhard> tiredbones: huh?
<tiredbones> a joke.
<reinhard> ah ok :)
<lekma> reinhard: the error i see most is related to self._dataObject being a NoneTYpe
<lekma> in Resultset.py
<lekma> s/NoneTYpe/NoneType
<lekma> so not having _unicodeMode or _connection attribute
<lekma> example
<reinhard> the other one might be easier to spot
<reinhard> ResultSet._dataObject is a public property, so it might get changed everywhere
<reinhard> geasList.__recordset is a private property, and we know for sure it must be one of the two lines that set it to None
<lekma> well atm i only see those:
<lekma> DB000: Exception in thread Thread-1859:
<lekma> DB000: Traceback (most recent call last):
<lekma> DB000:   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
<lekma> DB000:     self.run()
<lekma> DB000:   File "/var/lib/gnue/gecocer/xul/forms.py", line 231, in run
<lekma> DB000:     self.obj = self.attr.getXulAttr (self.obj, self.item)
<lekma> DB000:   File "/var/lib/gnue/gecocer/xul/attributes.py", line 133, in getXulAttr
<lekma> DB000:     attribs = self.__session.find (klass, cond, [], props)
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/Session.py", line 119, in find
<lekma> DB000:     properties)
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/ObjectList.py", line 48, in __init__
<lekma> DB000:     self.__buildList ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/ObjectList.py", line 108, in __buildList
<lekma> DB000:     self.__populateList ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/ObjectList.py", line 118, in __populateList
<lekma> DB000:     rset = sm.fetch (sid, self.__list_id, len (self.__list), self.__cacheStep,0)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasSessionManager.py", line 300, in fetch
<lekma> DB000:     result = s.fetch (list_id, start, count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasSession.py", line 467, in fetch
<lekma> DB000:     result = list.fetch (start, count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 260, in fetch
<lekma> DB000:     self.__fillupFunc (start + count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 76, in __fillupFunc
<lekma> DB000:     return self.__fillupUnsorted (count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 133, in __fillupUnsorted
<lekma> DB000:     current = self.__getInstance ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 163, in __getInstance
<lekma> DB000:     record = self.__recordset.nextRecord ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/data.py", line 973, in nextRecord
<lekma> DB000:     rec = self.__nextBackendRecord ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/data.py", line 1084, in __nextBackendRecord
<lekma> DB000:     beRec = self.__resultSet.firstRecord ()
<lekma> DB000:   File "/usr/lib/gnue/common/datasources/drivers/Base/
<lekma> DB000:   File "/usr/lib/gnue/appserver/data.py", line 1084, in __nextBackendRecord
<lekma> DB000:     beRec = self.__resultSet.firstRecord ()
<lekma> DB000:   File "/usr/lib/gnue/common/datasources/drivers/Base/ResultSet.py", line 175, in firstRecord
<lekma> DB000:     if not self._cacheNextRecord():
<lekma> DB000:   File "/usr/lib/gnue/common/datasources/drivers/Base/ResultSet.py", line 452, in _cacheNextRecord
<lekma> DB000:     rs = self._loadNextRecord()
<lekma> DB000:   File "/usr/lib/gnue/common/datasources/drivers/DBSIG2/ResultSet.py", line 97, in _loadNextRecord
<lekma> DB000:     f = unicode(f,self._dataObject._connection._encoding)
<lekma> DB000: AttributeError: 'NoneType' object has no attribute '_connection'
<lekma> D
<lekma> sorry too long
<reinhard> lekma: this is really weird
<reinhard> if you look at the line *exactly* above the last line of your traceback (line 97 in DBSIG2/ResultSet.py)
<reinhard> self._dataObject._unicodeMode is accessed there and doesn't raise an error
<reinhard> so it seems like another thread destroyed self._dataObject just between these 2 lines
<reinhard> even self._dataObject._connection is accessed right before in the same procedure
<reinhard> again in Base/RecordSet.py there is a close() function that sets self._dataObject to None
<reinhard> I suspect that close() gets called somehow
*** jamest_ has left #gnuenterprise
<lekma> did you mean Base/ResultSet.py ?
<reinhard> yes I think so
<lekma> does the resultset has any meaningful attr that can be linked to originating list??
<lekma> well don't ask me why but the resulset.close() is called for each and every list created
<reinhard> you could provoke a traceback there to find out who is calling that close()
<lekma> not by the xul engine and way before my rpc closeLists is triggered
<lekma> a raise is enough
<lekma> ?
<reinhard> raise Exception
<reinhard> or something like that
<reinhard> I have considered for a few times now adding a __repr__ function to objects
<reinhard> so they can call themselves names
<lekma> DB000:     self.__fillupFunc (start + count)
<lekma> DB000:    File "/usr/lib/gnue/appserver/geasList.py", line 76, in __fillupFunc
<lekma> DB000:     return self.__fillupUnsorted (count)
<lekma> DB000:    File "/usr/lib/gnue/appserver/geasList.py", line 133, in __fillupUnsorted
<lekma> DB000:     current = self.__getInstance ()
<lekma> DB000:    File "/usr/lib/gnue/appserver/geasList.py", line 177, in __getInstance
<lekma> DB000:     self.__recordset.close ()
<lekma> DB000:    File "/usr/lib/gnue/appserver/data.py", line 1018, in close
<lekma> DB000:     self.__resultSet.close ()
<lekma> DB000:    File "/usr/lib/gnue/common/datasources/drivers/Base/ResultSet.py", line 295, in close
<lekma> DB000:     raise Exception
<lekma> DB000:  Exception
<lekma> D
<lekma> the last lines
<lekma> it's geasList that close everything
<reinhard> ok so we're back to our self.__recordset.close() anyway
<reinhard> but that looks as if there are two fetch() running on the same list in parallel?
<reinhard> is there any means to see which thread you're in?
<reinhard> can you check whether geasList.__getInstance runs in 2 different threads for the same list?
<lekma> oh oh
<lekma> i don't know what it exactly mean but when i print self.__list_id
<lekma> in language/ObjectList.py
<lekma> in def --buildList
<lekma> sorry __buildList
<lekma> i get two lists with same id just before the error occur
<lekma> my guess would be both thread got same list id
<lekma> and at one point one finish its job then close the list
<lekma> the other thread then raise the error in the middle of its job
<reinhard> lekma: ok. got it
<reinhard> in geasSession, about line 397
<lekma> wow
<lekma> you're fast
<reinhard>     self.__listcount += 1
<reinhard>     self.__lists [self.__listcount] = list
<reinhard>     list_id = self.__listcount
<reinhard> thread a increments listcount
<reinhard> then thread switch
<reinhard> thread b increments listcount (of same session)
<reinhard> thread b gets current list id returned
<reinhard> thread switch back
<reinhard> thread a gets same list id returned
<reinhard> possible solution
<reinhard> use a good random number as list_id instead of the listcount
<reinhard> *or*
<reinhard> if there is any way to block thread switches between these 3 lines, that's even better
<lekma> no obvious solution from my part
<lekma> solution 2 is far too much work atm
<lekma> cause it would require
<lekma> geas to manage threads
<lekma> andd locks
<lekma> and i don't think it's in the roadmap
<reinhard> it could be a good idea to use the address of the newly created geasList object as the list id
<reinhard> that should be unique over all threads
<reinhard> (I *think* there is a way to find out the address of an object)
<reinhard> yes. id(object)
<reinhard> let me do a quick test
*** jamest has quit IRC
<reinhard> yes, seems to work
<reinhard> Index: geasSession.py
<reinhard> ===================================================================
<reinhard> --- geasSession.py      (Revision 7020)
<reinhard> +++ geasSession.py      (Arbeitskopie)
<reinhard> @@ -107,7 +107,6 @@
<reinhard>        self.database = "gnue"
<reinhard> 
<reinhard>      self.__lists          = {}
<reinhard> -    self.__listcount      = 0
<reinhard>      self.__authAdapter    = authAdapter
<reinhard>      self.__connection     = None
<reinhard>      self.__dirtyInstances = {}
<reinhard> @@ -271,7 +270,6 @@
<reinhard>        item.close ()
<reinhard> 
<reinhard>      self.__lists          = {}
<reinhard> -    self.__listcount      = 0
<reinhard>      self.__dirtyInstances = {}
<reinhard>      self.filters          = {}
<reinhard> 
<reinhard> @@ -393,9 +391,8 @@
<reinhard>      list = geasList.geasList (self, classdef, self.__connection, recordset,
<reinhard>                             [u'gnue_id'] + propertylist, asCond, dsSort, asSort)
<reinhard> 
<reinhard> -    self.__listcount += 1
<reinhard> -    self.__lists [self.__listcount] = list
<reinhard> -    list_id = self.__listcount
<reinhard> +    list_id = id (list)
<reinhard> +    self.__lists [list_id] = list
<reinhard> 
<reinhard>      return list_id
<reinhard> 
<reinhard> (that would be the diff in case you can't svn up for memory leak reasons)
<lekma> thx
<reinhard> in case you can svn up, I've also committed it
<lekma> i think i can't svn up geasSession since lasts changes johannes made
<lekma> Two objects whose lifetimes are disjunct may have the same id() value
<lekma> what mean disjunct
<lekma> ?
<reinhard> i think "non overlapping"
<lekma> ok
<siesel> hi
<lekma> yeah i understand while posting
<reinhard> it is the address of the object in memory
<lekma> hi siesel
<reinhard> so this is what would make sense
<siesel> hi lekma, hi reinhard
<reinhard> hi siesel
<lekma> funny all ids are negative
<lekma> :)
<reinhard> might have to do with python's memory management
<lekma> well the error seem to have disappear
<lekma> thx reinhard
<reinhard> wohooo
<siesel> lekma: you can do multithreaded requests now?
<lekma> not really from the xmlrpc interface
<siesel> so you directly use the api?
<lekma> i have a python xul engine that is now multithreaded
<lekma> and fast enough
<siesel> xul engine means mozilla?
<lekma> but rpc calls still seem not to be threaded
<lekma> yes mozilla at client side
<reinhard> lekma: so the rpc server does not create a new thread for rpc calls
<lekma> i initiate a rpc call that calls a python procedure that returns datat
<reinhard> but in some procedures you manually spawn off threads?
<lekma> yep
<lekma> that exactly it
<reinhard> I'm somehow shocked that we're appearantly closer to a thread safe appserver than i thought
<siesel> oops, too tired. Good night
*** siesel has quit IRC
<lekma> well if you initiate the thread soon enough
<lekma> appserver seems to be ok
<lekma> what would be great would be to have a thread per session
<lekma> and then spaw a child thread for every request/load/store inside the session
<reinhard> so actually a thread per rpc request?
<lekma> well that would be first step
<lekma> and a temporary solution for me
<reinhard> and what would be next steps?
* reinhard trying to understand
<lekma> a main thread per session that would spaw proc (find, ...) threads
<lekma> having one thread per call is great
<lekma> but it's better to have all thread from a session in jail in a session thread
<reinhard> I don't understand
<lekma> for you to kill a session
<lekma> for example
<reinhard> ah
<reinhard> can threads be hierarchical?
<lekma> would kill all running child threads of a session
<lekma> i think, but i'm far from being an expert
<lekma> i think that as soon as you spawn a thread from a thread
<lekma> it is a child thread of the launcher
<reinhard> hmmmm
<reinhard> so the "session father" thread would keep the connection to the client?
<lekma> why
<reinhard> how does that work actually? is there an open tcp/ip connection between appserver and the client during the lifetime of a session?
<lekma> ?
<lekma> nope
<lekma> you pass session id
<lekma> to each and every call
<reinhard> yes i know but
<reinhard> which thread would answer a new xmlrpc reqeust?
<lekma> except for open
<lekma> that has to create the session/thread object
*** titopbs has quit IRC
<lekma> the thread answering an rpc call would be the thread object attached/linked/representing the session
<reinhard> but how would that thread know it's "for him"?
<lekma> session id
<reinhard> before it can see the session id?
<lekma> i don't understand
<reinhard> because it can only see the session id when it already answered the rpc request?
<reinhard> i mean
<lekma> internally the session is created via rpc??
<reinhard> which thread would listen to port 7654?
<reinhard> (or whatever port you use with appserver)
<lekma> the actual xmlrpc server thread
<reinhard> but that "main listener" thread would have to pass the request to the "session" thread
<reinhard> right?
<lekma> yep
<reinhard> which would acutally mean another layer of rpc between these threads
<lekma> no
<lekma> how now a the server knows to which session give a request
<lekma> ?
<lekma> not give
<reinhard> now there's only a single thread
<lekma> how the actual server knows which session object is to be used when an rpc call is to be executed
<reinhard> not to find the session object is the problem
<lekma> yes but calls ar executed in the session context??
<reinhard> but to find the thread "responsible" for that session
<lekma> threads are objects
<reinhard> and to communicate with that thread
<lekma> so you could give a session object an attribute that could be rthe thread
<lekma> or the other way around
<lekma> :)
*** wendall911 has left #gnuenterprise
<lekma> remember i am not a programmer
* reinhard must learn more about threads
<lekma> so my ideas are to be taken with a huge grain of salt
<reinhard> another question
<reinhard> does the multithreading as you do now solve your performane problems?
<lekma> part of it
<lekma> now the forms are rendered much faster
<lekma> but you still have to wait for your colleagues requests to finish
<lekma> before going on
<reinhard> ... where threaded rpc requests would make a big change, right?
<lekma> yes
<lekma> definitely
<lekma> but it seems i was wrong the server is threaded...
<lekma> i need more testing
<reinhard> somehow it claims to be
<reinhard> but I don't understand much of common's xmlrpc code
<reinhard> :(
*** kilo has quit IRC
<reinhard> night all
*** reinhard has quit IRC
*** sjc has quit IRC
*** lekma has quit IRC
*** dcmwai has joined #gnuenterprise
*** jcater has quit IRC
*** holycow has joined #gnuenterprise
*** holycow has quit IRC