- Zope-Dev - Zope lists

Status of mod_pcgi?
by Andy Dustman 24 Aug '99

24 Aug '99

What is the status of mod_pcgi nowadays? The version I have (from June 20 or so) seems to work, but it does not work in conjunction with mod_rewrite. <light bulb>Since I can't rewrite URLs relative to the mount point, can I move the mount point to /?</light bulb> The answer is: Yes. That may well solve my major problem, while creating a new one. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d

1 0

zope.org
by Paul Prescod 24 Aug '99

24 Aug '99

I'm looking for a "search" button on www.zope.org. Didn't I see one there at one point? Paul Prescod

3 2

RE: [Zope-dev] Product initialization.
by Michel Pelletier 24 Aug '99

24 Aug '99

> -----Original Message----- > From: Andreas Kostyrka [mailto:andreas@mtg.co.at] > Sent: Tuesday, August 24, 1999 2:40 PM > To: Robin Becker > Cc: zope-dev(a)zope.org > Subject: Re: [Zope-dev] Product initialization. > > > On Tue, 24 Aug 1999, Robin Becker wrote: > > > In article > <Pine.LNX.4.10.9908241833460.3968-100000(a)gatekeeper.zwax.mtg. > > co.at>, Andreas Kostyrka <andreas(a)mtg.co.at> writes > > >Hi! > > > > > >I've been wondering if there is a way to specify the > initialisation order > > >of products? Or is there some defined order already? > > > > > >This would be important for Products that enhance existing > Products. > > >(For this scenario, a function "Require_Product(name)" > would be most > > > beneficial.) > > > > > what's wrong with "import name"? > Well, does it work this way? ;) > (if so, I've just again proved that I classify in "dummy users") > It is safe to import something if it is allready imported. Python will not 'reimport' the module, it will just use the allready imported one. This removes the need for any kind of dependancy type method. Thank Guido. -Michel > Andreas > -- > Andreas Kostyrka | andreas(a)mtg.co.at > phone: +43/1/7070750 | phone: +43/676/4091256 > MTG Handelsges.m.b.H. | fax: +43/1/7065299 > Raiffeisenstr. 16/9 | 2320 Zwoelfaxing > AUSTRIA > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For non-developer, user-level issues, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

2 1

Solid DA patches to handle closed conns
by Andrew M. Kuchling 24 Aug '99

24 Aug '99

Last month I reported that the Solid DA choked when the database server closed the connection on it. Today I looked into it and have some patches (included below); they fix some fairly serious problems, but more still remain. It turns out that ZSolidDA/db.py actually had code to reopen closed connections, but it was never triggered because an except statement used the wrong exception object. Fixing this slip exposed worse problems than the original typo. The first and most critical problem is that when you free a Statement object whose database connection has been closed, you get a core dump. This doesn't seem to be the DA's fault, but rather stems from the libraries in Solid 2.3. I couldn't fix the core dump, so instead the patch rearranges ZSolidDA/db.py to only create self.stmt when it's required, and doesn't copy self.stmt into a local variable, because the statement object might change along the way if .connect() gets called. The second fix is to the C module; the _dealloc() routine for Connection objects raises an exception if there's an error on the SQLDisconnect(), including if the connection was already closed. The patch to pysql.c suppresses the exception if it was a connection-related error. The patches seem to work in my tests, but my findings cast an extremely disturbing light on the stability of Solid's libraries. -- A.M. Kuchling http://starship.python.net/crew/amk/ Advertising reaches out to touch the fantasy part of people's lives. And you know, most people's fantasies are pretty sad. -- Frederik Pohl, _The Way The Future Was_ *** db.py 1999/08/24 16:03:40 1.1 --- db.py 1999/08/24 18:46:50 *************** *** 97,102 **** --- 97,104 ---- + import sql from sql import SQLConnection, SQLDataSources, SQLDescribeCol, SQLExecDirect from sql import SQLFetch, SQLFreeStmt, SQLGetString, SQLNumResultCols + from sql import SQLDisconnect from sql import SQLSetConnectOption, SQLTables, SQLTransact, SQL_AUTOCOMMIT from sql import SQL_AUTOCOMMIT_OFF, SQL_BIGINT, SQL_BINARY, SQL_BIT, SQL_CHAR *************** *** 177,185 **** self._connect() def _connect(self): self.connection=c=apply(SQLConnection, self._connection_info) try: SQLSetConnectOption(c,SQL_AUTOCOMMIT,SQL_AUTOCOMMIT_OFF) except: pass # Oh well - self.stmt=c() def _apply(self, f, args): --- 179,192 ---- self._connect() + def _connect(self): + if hasattr(self, 'connection'): + try: + del self.stmt + del self.connection + except: pass self.connection=c=apply(SQLConnection, self._connection_info) try: SQLSetConnectOption(c,SQL_AUTOCOMMIT,SQL_AUTOCOMMIT_OFF) except: pass # Oh well def _apply(self, f, args): *************** *** 187,198 **** # Checks for stale connections. try: return apply(f, args) ! except error, v: try: tb=sys.exc_traceback state, native, mess = v if state[:2]=='08': ! # Hm, spells like a connection failure. # Let's connect and try again. self._connect() return apply(f, (self.stmt, ) + args[1:] ) raise error, v, tb --- 194,208 ---- # Checks for stale connections. try: return apply(f, args) ! except (error, sql.error), v: try: tb=sys.exc_traceback state, native, mess = v if state[:2]=='08': ! # Hm, smells like a connection failure. # Let's connect and try again. self._connect() + # _connect() creates a new value of self.stmt, so + # we need to use args with the new value of self.stmt. + self.stmt = self.connection() return apply(f, (self.stmt, ) + args[1:] ) raise error, v, tb *************** *** 200,203 **** --- 210,214 ---- def table_info(self): + self.stmt = self.connection() self._apply(SQLTables,(self.stmt, None, None, None, 'TABLE')) r=[] *************** *** 212,223 **** def tables(self, Qualifier=None, Owner=None, Name=None, Type=None, rdb=1): self._apply(SQLTables,(self.stmt, Qualifier, Owner, Name, Type)) return self.query(rdb=rdb) def query(self, src=None, max_rows=99999999, rdb=1): - stmt=self.stmt self._register() try: if src is not None: r=filter(strip,split(src,'\0')) if not r: raise ValueError, 'null sql' --- 223,235 ---- def tables(self, Qualifier=None, Owner=None, Name=None, Type=None, rdb=1): + self.stmt = self.connection() self._apply(SQLTables,(self.stmt, Qualifier, Owner, Name, Type)) return self.query(rdb=rdb) def query(self, src=None, max_rows=99999999, rdb=1): self._register() try: if src is not None: + self.stmt = self.connection() r=filter(strip,split(src,'\0')) if not r: raise ValueError, 'null sql' *************** *** 225,230 **** res=None for s in r: ! self._apply(SQLExecDirect,(stmt,s)) ! status, ncol = SQLNumResultCols(stmt) if ncol: if res is not None: --- 237,242 ---- res=None for s in r: ! self._apply(SQLExecDirect,(self.stmt,s)) ! status, ncol = SQLNumResultCols(self.stmt) if ncol: if res is not None: *************** *** 237,247 **** return res ! self._apply(SQLExecDirect,(stmt,src)) ! except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! status, ncol = SQLNumResultCols(stmt) if ncol==0: if rdb: return "x\n8s\n" --- 249,260 ---- return res ! self._apply(SQLExecDirect,(self.stmt,src)) ! except KeyError, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! ! status, ncol = SQLNumResultCols(self.stmt) if ncol==0: if rdb: return "x\n8s\n" *************** *** 254,258 **** binary_flags=[0]*ncol for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(stmt,i+1) names[i]=name if prec < 1: prec=8 --- 267,271 ---- binary_flags=[0]*ncol for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(self.stmt,i+1) names[i]=name if prec < 1: prec=8 *************** *** 269,276 **** r.append(join(row,'\t')) ! status=SQLFetch(stmt) while status==SQL_SUCCESS: for i in range(ncol): ! v=SQLGetString(stmt,i+1,binary_flags[i]) if rdbdefs[i]=='t': if find(v,'\\') >= 0: v=join(split(v,'\\'),'\\\\') --- 282,289 ---- r.append(join(row,'\t')) ! status=SQLFetch(self.stmt) while status==SQL_SUCCESS: for i in range(ncol): ! v=SQLGetString(self.stmt,i+1,binary_flags[i]) if rdbdefs[i]=='t': if find(v,'\\') >= 0: v=join(split(v,'\\'),'\\\\') *************** *** 283,305 **** for i in indexes: rd[names[i]]=row[i] r.append(rd) ! status=SQLFetch(stmt) ! SQLFreeStmt(stmt, SQL_CLOSE); if rdb: r=join(r,'\n')+'\n' return r def columns(self, table_name): - stmt=self.stmt try: self._apply(SQLExecDirect, ! (stmt, 'select * from %s where 1=2' % table_name)) except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! status, ncol = SQLNumResultCols(stmt) r=[] standard_type=tpnames.has_key for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(stmt,i+1) if standard_type(tp): tp=tpnames[tp] else: tp="Non-standard type %s" % tp --- 296,317 ---- for i in indexes: rd[names[i]]=row[i] r.append(rd) ! status=SQLFetch(self.stmt) ! SQLFreeStmt(self.stmt, SQL_CLOSE); if rdb: r=join(r,'\n')+'\n' return r def columns(self, table_name): try: self._apply(SQLExecDirect, ! (self.stmt, 'select * from %s where 1=2' % table_name)) except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! status, ncol = SQLNumResultCols(self.stmt) r=[] standard_type=tpnames.has_key for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(self.stmt,i+1) if standard_type(tp): tp=tpnames[tp] else: tp="Non-standard type %s" % tp *************** *** 308,312 **** 'Nullable': nullable and 'with Null' or ''}) ! SQLFreeStmt(stmt, SQL_CLOSE); return r --- 320,324 ---- 'Nullable': nullable and 'with Null' or ''}) ! SQLFreeStmt(self.stmt, SQL_CLOSE); return r *** /tmp/ZSolidDA/src/pysql.c Mon Jan 11 11:43:17 1999 --- pysql.c Tue Aug 24 14:41:17 1999 *************** *** 119,124 **** UNLESS(SQLDisconnect(self->connection) == SQL_SUCCESS && SQLFreeConnect(self->connection) == SQL_SUCCESS) ! PyErr_SetString(PyExc_SQLError, ! "error in SQL connection destructor"); } PyMem_DEL(self); --- 119,141 ---- UNLESS(SQLDisconnect(self->connection) == SQL_SUCCESS && SQLFreeConnect(self->connection) == SQL_SUCCESS) ! { ! char state[6]; ! SDWORD native; ! char mess[SQL_MAX_MESSAGE_LENGTH]; ! SWORD lmess; ! ! SQLError(SQLEnv, self->connection, SQL_NULL_HSTMT, ! state,&native, ! mess,SQL_MAX_MESSAGE_LENGTH-1,&lmess); ! ! /* Only raise an exception if the state code doesn't begin ! with '08'; '08' means a connection error, and we don't ! care about connection errors when we're *closing* a connection. ! */ ! if (state[0]=='0' && state[1] == '8') ! { ! PyErr_Clear(); ! } ! } } PyMem_DEL(self);

1 0

Re: [Zope-dev] CatalogAware must come before ObjectManager
by Andreas Kostyrka 24 Aug '99

24 Aug '99

On Thu, 5 Aug 1999, Michel Pelletier wrote: > It is possible, but only from python, and it is a *real* hack. Doing > this is completely unsupported. I might get shot for revealing the > technique. Well, so it may be well, that I'm far far away on the other side of the big pond ;) Actually, if you need this, I might send you an image of my person, so you can print it out and play Darts. But then, perhaps I should just write a special Emacs mode for editing python source, and enforce it's usage at Digital Creations: As a special feature, this mode would treat lines the contain the keyword "class" as readonly. Yep. And if you want to change the base classes afterwards, you just delete the .py file and type it from the beginning. > Given a Product called 'YourProduct' that contains a Zclass called > 'YourZClass' that you want to 'rebase', first, create a temporary ZClass > called 'TempZClass' in the same product. 'TempZClass' should be built > with the new order or types of subclasses that you want 'YourZClass' to > have. Note that 'TempZClass' need not have anything in it, it just > needs to subclass the right classes. > > Shut down Zope, run python1.5.2 in your lib/python directory, and > execute the following code: > > >>> import Zope > >>> p = Zope.app().Control_Panel.Products.YourProduct > >>> p > <Product instance at 849de28> > >>> p.YourZClass._setBasesHoldOnToYourButts(p.TempZClass._zbases[1:]) > >>> get_transaction().commit() Well, install the attached zc.py in your Externals directory. Add external methods zc_copybases and zc_show (mapped to zc.py/copybases and zc.py/show) somewhere in your ZOPE. For demonstration I assume it's in your root folder, and your zope server is called http://myzope/. Well, then use your browser to visit the following URLs (this does more or less exactly what the above python magic does): http://myzope/zc_show?zclass=YourZClass&product=YourProduct http://myzope/zc_show?zclass=TempZClass&product=YourProduct This shows you the baseclasses of the two Z classes. http://myzope/zc_copybases? srczclass=TempZClass&srcproduct=YourProduct& dstzclass=YourZClass&dstproduct=YourProduct (This should be a one line URL.) This does the voodoo magic above. And completly without shutting down your ZOPE, and it does even comment the transaction nicely. (Interesting question if it is undoable.) And yes, the attached file is twice unsupported ;) 1.) The voodoo is not supported by Digital Creations, so it may change at any time. 2.) The external module is not supported by MTG, as its voodoo coefficient is to high. Andreas -- Andreas Kostyrka | andreas(a)mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA

1 0

RE: [Zope-dev] Python & XML what about Java
by Michel Pelletier 24 Aug '99

24 Aug '99

> -----Original Message----- > From: Cory L Hubert [mailto:clhubert@netzero.net] > Sent: Tuesday, August 24, 1999 3:13 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Python & XML what about Java > > > > Hey. I am new to Zope. I just tripped over it the > other day and I am > extremly interested. The only thing I am concerned about is > Zope's XML > support. A lot of XML projects I am getting involved in > require Java and > Java Servlets (for obvious reasons). Zope seems to take the > python route to > supporting XML. > Does Zope's have any Java support? If not, does it > have plans to support > Java/XML. > I think Zope would make an excellent java servlet platform. You'd just have to write the plumbing to connection the Zope object model to Java. Note that this is a very clean mapping, just look at JPython. The Apache folks have been doing some good development along these lines, perhaps much of their effort can be integrated into a plug-in for Zope. Also, I don't think there is way that much more XML functionality in Java than in Python. Python takes a route where you are given a small set of very powerful tools, and then a super clean fast-development scripting language (python) to glue them together. I would think that developing XML apps in Python takes as much time as doing them in Java, even with all the gobs and gobs of Java tools that exist at the moment. -Michel > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For non-developer, user-level issues, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0

Try tag with else block, or finally block
by Martijn Pieters 24 Aug '99

24 Aug '99

Hello fellow Zope developers I extended the new 'try' tag to include support for an optional 'else' block, and whipped in support for 'try..finally' as well. The try tag now has this form: try [[except]* [else] | [finally]] /try. I also added more rigorous checks on it's syntax, like allowing only one default exception handler. Attached you'll find a patch against the latest CVS, but it will work on Zope 2.0a4 and higher. The file to patch is lib/python/DocumentTemplate/DT_Try.py. Let me know what you'll think. I'll post this patch to the Collector as well. Here is it's documentation string: Zope DTML Exception handling usage:       or:    The DTML try tag functions quite like Python's try command. The contents of the try tag are rendered. If an exception is raised, then control switches to the except blocks. The first except block to match the type of the error raised is rendered. If an except block has no name then it matches all raised errors. The try tag understands class-based exceptions, as well as string-based exceptions. Note: the 'raise' tag raises string-based exceptions. Inside the except blocks information about the error is available via three variables. 'error_type' -- This variable is the name of the exception caught. 'error_value' -- This is the caught exception's value. 'error_tb' -- This is a traceback for the caught exception. The optional else block is rendered when no exception occurs in the try block. Exceptions in the else block are not handled by the preceding except blocks. The try..finally form specifies a `cleanup` block, to be rendered even when an exception occurs. Note that any rendered result is discarded if an exception occurs in either the try or finally blocks. The finally block is only of any use if you need to clean up something that will not be cleaned up by the transaction abort code. The finally block will always be called, wether there was an exception in the try block or not, or wether or not you used a return tag in the try block. Note that any output of the finally block is discarded if you use a return tag in the try block. If an exception occurs in the try block, and an exception occurs in the finally block, or you use the return tag in that block, any information about that first exception is lost. No information about the first exception is available in the finally block. Also, if you use a return tag in the try block, and an exception occurs in the finally block or you use a return tag there as well, the result returned in the try block will be lost. Original version by Jordan B. Baker. Try..finally and try..else implementation by Martijn Pieters. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------

1 0

Acqusition
by Dody Gunawinata 24 Aug '99

24 Aug '99

i'm still puzzled about the concept of Acqusition. It states that the object in Zope can read settings from it's environment, and all the example i've been reading is about reading the folder id properties (yeah, and that person phone number etc). my question : is it possible to introduce more custom properties into folders ? dody italy

2 2

RE: [Zope-dev] Speed..
by Paul Everitt 23 Aug '99

23 Aug '99

If I remember correctly, this issue came up several months ago and the answer was Windows network lookups. Are you perchance working offline when you experience the slowdowns? Don't worry, I can guarantee you that Zope 1.10.3 on a Win95, 166 Mhz machine will do several hits per second. What you are seeing is Zope not being configured correctly (unfortunately I don't remember the answer). --Paul > -----Original Message----- > From: Dody Gunawinata [mailto:dody_g@eles.com] > Sent: Saturday, September 25, 1999 8:15 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Speed.. > > > > Hi all, > > i'm running Zope on with P-200 64 Mb Win95-OSR 2 with ZoneHttpServer. > And it's slow (really slow, it takes about 15 seconds in local machine > just for the browser to properly display the management console) > > I've tried to switched the python int shipped with the > package to my own > full python installation, and it still is slow. > > Anyway have an advice on speeding it up ? Could it be the built in > webserver that is slow ? > > thanks > > dody, > italy > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For non-developer, user-level issues, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

2 1

Speed..
by Dody Gunawinata 23 Aug '99

23 Aug '99

Hi all, i'm running Zope on with P-200 64 Mb Win95-OSR 2 with ZoneHttpServer. And it's slow (really slow, it takes about 15 seconds in local machine just for the browser to properly display the management console) I've tried to switched the python int shipped with the package to my own full python installation, and it still is slow. Anyway have an advice on speeding it up ? Could it be the built in webserver that is slow ? thanks dody, italy

3 2