- Zope-Dev - Zope lists

BTree fixes in a release?
by seb bacon 23 Jun '03

23 Jun '03

There lave been various BTree fixes lounging in the HEAD since Jan 2003 which I'd like to get into a release, basically because we have seen one of the bugs causing segfaults in production - this is the culprit: http://cvs.zope.org/Zope/lib/python/BTrees/BTreeItemsTemplate.c.diff?r1=1.1… a) Any reason why I shouldn't merge it into the 2.6 branch? b) Any chance of a 2.6.2b3? Seb

3 4

funky side-effects, possible bug in HTTPRequest.py
by Jamie Heilman 23 Jun '03

23 Jun '03

The last few days I've been working on patch to Zope 2 that will clean up the textarea size preference handling in the ZMI. Right now, its a mess. I kept running into this really irritating behavior such that, when ever I'd go to pull something out of a request object, it'd end up being found in the 'other' dictionary instead of where I expected to be (which happened to be 'form'). After getting really curious as to why this was happening I've managed to track it down to subtle a change in the way that the HTTPRequest.get method worked between revisions 1.75 and 1.74 (1.75 being mj's merge of the value tainting code). The code responsible (assuming the value isn't tainted): # Untrusted data *after* trusted data v = self.form.get(key, _marker) if v is not _marker: other[key] = v # *boom* return v That magical promotion of the key & value to the other dictionary is what tripped me up. This technique, while originally used only for known convenience variables like URLx or BASEx and for promoting lazy data, now applies to all variables after revision 1.75. (This isn't the only spot it gets used now, the tainting changes made it affect form values, cookies, tainted form values, etc.) It would increase the speed at which variables are found--but I'm not sure its really an intended side effect, and now I'll explain how I was bitten by it. Its not unusual to see people write methods to be published that are similar too: manage_main = DTMLFile("edit", globals()) def manage_changeFoo(self, REQUEST, something=None, or_other=628): # stuff return self.manage_main(self, REQUEST) They're a dime a dozen, yay neat. What sometimes makes them more interesting is when people modify the REQUEST dictionaries to pull off various behind the scenes fake-like-we-requested-it-that-way stuff. This is what several of the methods that handled the Taller, Wider, Narrower, etc. buttons on text area prefs did, and thats why I ran into it. One of these methods did: REQUEST.form.update({'something':'x', 'or_other':'y'}) and then it returned a DTMLFile plied with the snazzy new request that had been tricked out with these fake values now stuck into the form dictionary. This explains the TALES I saw that was "request/form/something | request/something | default" which when I first saw made wonder if the author was on acid. It was clear to me that 'something' would never be in other, it wasn't a special variable and it wasn't being explicitly stuck into the other dictionary by the code, so why the redundant TALES I wondered? I removed the first statement, and it broke the functionality. Hmmm! Until about 20 minutes ago I didn't understand exactly how object methods got published, but I tracked down the code in Publish.py and found the mapply() function and now its all clear to me what was happening. The request object gets mapply'd to the published method, this means that any positional arguments or any keyword arguments will get HTTPRequest.get'd out of the request object when they are applied to the published method, and thanks to the side-effects from revision 1.75 on, it also means any named variables in a method definition will be promoted into the HTTPRequest.other dictionary. Now, let me just say - if thats how its supposed to be, so be it - but spin my nipple nuts and call me Frank, this does NOT strike me as terribly intuitive behavior. Anyway, it was a learning experience for me, but I'm not convinced this isn't a bug. What do you think? (the patches I spoke of should be ready sometime tomorrowish assuming I don't run into any other funkyness, I'll post them to the collector) -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz

7 9

Memory Error
by Andy McKay 23 Jun '03

23 Jun '03

If you've visited ZopeZen you might have noticed this lovely error that seems to occur intermittently.. [snip rest of traceback] * Module Products.CMFCore.CatalogTool, line 214, in searchResults * Module Products.ZCatalog.ZCatalog, line 619, in searchResults * Module Products.ZCatalog.Catalog, line 732, in searchResults * Module Products.ZCatalog.Catalog, line 480, in search * Module Products.PluginIndexes.common.UnIndex, line 365, in _apply_index * Module ZODB.Connection, line 534, in setstate MemoryError: (Also, an error occurred while attempting to render the standard error message.) Its: Zope 2.6.1 (source release, python 2.1, linux2) python 2.1.3 openbsd3 I believe all the appropiate python stack patches are applied. Any ideas? -- Andy McKay http://www.agmweb.ca

5 7

ZEO.auth missing from setup.py
by Adrian van den Dries 23 Jun '03

23 Jun '03

ClientStorage imports auth, which is not installed. Index: setup.py =================================================================== RCS file: /cvs-repository/Zope/setup.py,v retrieving revision 1.30 diff -u -r1.30 setup.py --- setup.py 13 Jun 2003 06:27:18 -0000 1.30 +++ setup.py 23 Jun 2003 05:15:24 -0000 @@ -655,7 +655,7 @@ name='ZEO', author=AUTHOR, - packages=['ZEO', 'ZEO.tests', 'ZEO.zrpc'], + packages=['ZEO', 'ZEO.auth', 'ZEO.tests', 'ZEO.zrpc'], data_files=[['ZEO', ['ZEO/*.txt', 'ZEO/*.xml']]], ) a. -- Adrian van den Dries avdd(a)flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au

1 0

Patching object class
by Florent Guillaume 20 Jun '03

20 Jun '03

I have the need to "update" some persistent objects in a ZODB to change their class. One use case comparable to the one I have would be to change all objects of type Folder to OrderedFolder. To do that, I envisionned finding all thoses objects and doing ob.__class__ = OrderedFolder ob._p_changed = 1 Would this work ? If not, what other hack could I do ? The idea being that I don't want to recreate all the objects. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

5 6

2.7 installation
by Adrian van den Dries 20 Jun '03

20 Jun '03

My company has a business need for better Debian packages of Zope (and particularly, packages of ZEO). I have outlined a proposal for an installation regime that will greatly simplify installation in a UNIX environment, with a configuration that Debian would use for installation. I bring it up here because my proposal probably requires some changes to the source tree which may suit being accepted upstream, and because we have a (sponsored) opportunity to hone Zope for a Debian environment (a not uncommon and very high-quality distrubution). I am, however, not yet familiar enough with the distutils to know if this regime is possible, nor am I familiar with the Windows installation. Also, it pushes my relentless agenda to get the standalone packages of Zope packaged as separate dependencies which may, I sense, not suit everyone! ;-) It is at http://homepages.flow.com.au/~avdd/zope-newinstall.html and included here. Comments? Cc'ed current Debian maintainers for completeness. =================================== Zope installation overhaul proposal =================================== The Problem +++++++++++ I have some concerns about the new installation mechanism, particularly how it will work for a UNIX (specifically Debian) install. Currently, a configure script (written in Python) writes a makefile, which installs software into the --prefix, as per custom:: $ ./configure --prefix=$PREFIX $ make $ sudo make install This installs the software under ``$PREFIX``, producing this layout:: $PREFIX/ bin/ doc/ import/ lib/ skel/ utilities/ You then make an instance:: $ /usr/lib/zope/bin/mkzopeinstance $INSTANCE This creates a Zope instance in $INSTANCE, like so:: $INSTANCE/ Extensions/ Products/ bin/ etc/ import/ log/ var/ The problems with this procedure are: 1. one --prefix is too limiting with this tree. You can't install into an existing hierarchy like /usr, because of the zope-specific directories "import", "skel" and "utilities". 2. $INSTANCE/bin/* are just shell wrappers for their respective scripts in $PREFIX/bin, serving only to point to the correct configuration and software paths, also requiring you to supply a full path to the script. This should instead be a global control script that takes an instance name as an argument: # zopectl -i default start 3. This installs all of Zope, ZODB, ZEO and zdaemon. I am uncomfortable with this blurring of function between applications (runzeo.py) and libraries (ZODB) ... probably more ... skip to solution: The Solution ++++++++++++ For Zope ======== The make install step:: EXECPREFIX=$PREFIX LIBPREFIX=$PREFIX SKELPREFIX=$PREFIX DOCPREFIX=$PREFIX BIN=$EXECPREFIX/bin LIB=$LIBPREFIX/lib # python, etc. DOC=$DOCPREFIX/doc SKEL=$SKELPREFIX/skel With ``PREFIX=/zope``, you get:: /zope/bin/ zopectl.py runzope.py utils.py etc. /zope/doc/ import/ Examples.zexp README.txt etc. /zope/lib/ python, etc /zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ Then the administrator (or initial installation) runs:: # mkzopeinstance /var/lib/zope/default/var -l /var/log/zope/default which copies ``$SKEL/*`` to ``/var/lib/zope/default``. To start, stop, restart zope:: # zopectl default (start|stop|status|restart|etc) Other Z* packages ================= Note that the above procedure installs only Zope. It requires ZODB (a standalone package) to be installed. ZEO is a separate package. It installs similarly to Zope, with instances similarly created with ``$PREFIX/bin/mkzeoinstance``. This may require some changes to the source tree. The Debian package ================== Debian's package would use:: PREFIX=/usr SKEL=$PREFIX/share/zope/skel DOC=$PREFIX/share/doc/zope Producing this layout:: /usr/bin/ zopectl.py runzope.py utils.py etc. /usr/share/doc/zope/ import/ Examples.zexp README.txt etc. /usr/lib/ python, etc /usr/share/zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ The Debian installation would create a default instance, possibly prompting for the name (otherwise "default"). It would also create: - ``/etc/init.d/zope`` (starts the first instance, or all instances) - ``/etc/default/zope`` (lists instances) Debian's ``mkzopeinstance`` would symlink ``/etc/zope/$INSTANCE`` to ``/var/lib/zope/$INSTANCE/etc`` (like postgresql), and it may provide the ``-l`` option to override the log location Debian packages ZEO and the ZODB similarly, and ZEO and Zope depend on the ZODB. a. -- Adrian van den Dries avdd(a)flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au

11 45

leave application in zpt + formulator
by nagendra prasad 20 Jun '03

20 Jun '03

hi i had downloaded leave.zexp from the following url http://www.openflow.it/EN/Download/index_html I have installded open flow 1.1.0 i have plone,zope on ,my linux box. Now i tried to rewrite the application using zpt + formulator(originally written in dtml). I have written the following zpt files 1)leave_startform_zpt 2)leave_start_zpt & a macro leaveform_macro for leave_startform_zpt file. Now my program goes like this leave_startform_zpt --> macros --> leave_start_zpt --> gotoOF (this is a python file), Plz see the files in the attachemnt. These are the files i have added. the other files remain same. no change I get the following error like Error Type NameError Error Value global name 'workflow' is not defined what is the problem plz help me thanks prasad ________________________________________________________________________ Send free SMS using the Yahoo! Messenger. Go to http://in.mobile.yahoo.com/new/pc/ 1) leave_startform_zpt ----------------------------------------------------------------------- <html> <head><tb> <title tal:content="template/title">The title</title> <head> <body> <p metal:use-macro="here/common_pages/macros/leaveform_macro" /> </body> </html> ----------------------------------------------------------------------- 2) leaveform_macro ----------------------------------------------------------------------- <div metal:define-macro="leaveform_macro"> <form name="leave_startform_formulator" method="post" action="leave_start_zpt"> <table tal:define="form here/leave_startform_formulator" align=center> <tr tal:define="startdate request/startdate|nothing"> <th align="left"> <font size=5><font face="verdana"><b> Start Date: </b></font></font> </th> <td><input type="text" name="startdate" tal:replace="structure python:form.startdate.render(startdate)" /> </td> </tr> <tr tal:define="enddate request/enddate|nothing"> <th align="left"> <font size=5><font face="verdana"><b> End Date: </b></font></font> </th> <td><input type="text" name="enddate" tal:replace="structure python:form.enddate.render(enddate)"> </td> </tr> <tr tal:define="reason request/reason|nothing"> <th align="left"> <font size=4><font face="verdana"><b> Reason: </b></font></font> </th> <td>><textarea type="text" name="reason" tal:replace="structure python:form.reason.render(reason)"></textarea> </td> </tr> <tr tal:define="leavetype request/leavetype|nothing"> <th align="left"> <font size=4><font face="verdana"><b> LEA: </b></font></font> </th> <td><textarea type="text" name="leavetype" tal:replace="structure python:form.leavetype.render(leavetype)"></textarea> </td> </tr> <tr cols="*,350,*"> <td> </td> <td align=center><input type="submit" value=" Submit "></td> <td> </td> </tr> </table><br> </form> </div> ----------------------------------------------------------------------- 3) leave_start_zpt ----------------------------------------------------------------------- <html> <head>  </head> <body bgcolor="#ffffff"> <p tal:replace="structure python:here.gotoOF()" />   </body> </html> ----------------------------------------------------------------------- 4) gotoOF ----------------------------------------------------------------------- no parametres for this. instance="workflow.addInstance('leaverequest',AUTHENTICATED_USER.getUserName(),'no comment','Request for leave by ' + AUTHENTICATED_USER.getUserName(), activation=0)" instobj="_.getattr(workflow,instance)" form = context.leave_startform_formulator instobj=getattr(workflow,instance) instobj.manage_addProperty('startdate', startdate, 'string') instobj.manage_addProperty('enddate', enddate, 'string') instobj.manage_addProperty('reason', reason, 'text') instobj.manage_addProperty('leavetype', leavetype, 'string') instobj.manage_addProperty('requested', '', 'string') instobj.manage_addProperty('formalia', '', 'string') instobj.manage_addProperty('approved', '', 'string') instobj.manage_addProperty('decision', '', 'text') workflow.startInstance(instance) print "Done" return printed -----------------------------------------------------------------------

1 0

./configure on Zope27HEAD with Python 2.2.2
by PieterB 20 Jun '03

20 Jun '03

Hi, Just ran ./configure using Python 2.2.2. I got the following output: (on FreeBSD 5.0) Configuring Zope installation Testing for an acceptable Python interpreter... Python version 2.2.2 found at /usr/local/bin/python let: arith: syntax error: "i = i + 1" let: arith: syntax error: "i = i + 1" [: 1: unexpected operator let: arith: syntax error: "i = i + 1" [: 1: unexpected operator let: arith: syntax error: "i = i + 1" [: 1: unexpected operator let: arith: syntax error: "i = i + 1" FreeBSD's shell doesn't support let "i=i+1" constructs: It works fine if I change the shell to /usr/local/bin/bash. An ugly fix seems to be to rename configure to configure.bash and create a configure such as: #!/bin/sh # force bash shell `which bash` ./configure.bash Other fix is to explain in the docs that you need to run bash ./configure on systems such as FreeBSD Anybody knows a nicer way to fix this? Pieter

4 5

A-A-P and Zope 2.7 issues
by PieterB 20 Jun '03

20 Jun '03

Hi, I created a first draft cut of a A-A-P file for Zope/Python and Zope products. I think of using it for creating a zopetest "product" and a new FreeBSD zopetest port (a Makefile that uses 'aap' and can be used to create several zopeinstances with several sets of products. I also would like to write some scripts which can be used to do functional/performance tests (on the various Zope/Python versions on various platforms). I think that would really be usefull for the Zope continuous integration process. The current script (invoke with 'aap') downloads Python 2.2.3 and PyXML, builds and tests Python, gets Zope from CVS and configures Zope. Have a look at: http://gewis.nl/~pieterb/zope/zopetest/main.aap-v0.01.txt and rename it to main.aap. Some Zopeissues I ran into: --------------------------------------------------- As a followup to: http://collector.zope.org/Zope/952 When you specify a python using --with-python you don't get warned about whether you use a non-optimal python or not. Maybe it's also good to mention the user that he/she IS using the optimal python version, when he/she does so. -------------------------------------------------- Please rename the makefile to Makefile --------------------------------------------------- zopectl has a hardcoded PYTHON variable set to: PYTHON="/usr/local/bin/python" shouldn't it use the --with-python version? ------------------------------------------------------- ZConfig requires PyXML. Default Python doesn't provide it. Both zopectl using Python 2.2.2 and Python 2.2.3 give the following traceback: ./zopectl start Traceback (most recent call last): File "/tmp/zope/lib/python/Zope/Startup/zopectl.py", line 148, in ? main() File "/tmp/zope/lib/python/Zope/Startup/zopectl.py", line 131, in main options.realize(args) File "/tmp/zope/lib/python/Zope/Startup/zopectl.py", line 80, in realize ZDOptions.realize(self, *args, **kw) File "/tmp/zope/lib/python/zdaemon/zdoptions.py", line 257, in realize self.load_schema() File "/tmp/zope/lib/python/zdaemon/zdoptions.py", line 298, in load_schema self.schema = ZConfig.loadSchema(self.schemafile) File "/tmp/zope/lib/python/ZConfig/loader.py", line 36, in loadSchema return SchemaLoader().loadURL(url) File "/tmp/zope/lib/python/ZConfig/loader.py", line 70, in loadURL return self.loadResource(r) File "/tmp/zope/lib/python/ZConfig/loader.py", line 134, in loadResource self.registry, self) File "/tmp/zope/lib/python/ZConfig/schema.py", line 42, in parseResource xml.sax.parse(resource.file, parser) File "/usr/local/lib/python2.2/xml/sax/__init__.py", line 30, in parse parser = make_parser() File "/usr/local/lib/python2.2/xml/sax/__init__.py", line 93, in make_parser raise SAXReaderNotAvailable("No parsers found", None) xml.sax._exceptions.SAXReaderNotAvailable: No parsers found Shouldn't ./configure already check this? ------------------------------------------------------------------ The doc/INSTALL.txt states: The Python you run Zope with *must* have threads compiled in, which is the case for a vanilla build. Warning: Zope will not run with a Python version that uses libpth. You *must* use libpthread. Can this be checked when running ./configure?

1 0

RE: [Zope-dev] Hi, new to zope
by Ramon Linan 19 Jun '03

19 Jun '03

Hi Andreas it worked!!!! that file was owned by root, although it has 777 permission.!!?? anyway, I worked after the zope user took control of the file and also after putting in z2.py those lines...thanks -----Original Message----- From: Andreas Jung [mailto:andreas@andreas-jung.com] Sent: Thursday, June 19, 2003 10:51 AM To: Ramon Linan Cc: zope-dev(a)zope.org Subject: RE: [Zope-dev] Hi, new to zope And maybe check the filepermissions of your _mysql.so file! It must be readable by python! -aj --On Donnerstag, 19. Juni 2003 16:41 Uhr +0200 Andreas Jung <andreas(a)andreas-jung.com> wrote: > add the following to your z2.py: > > import sys > print sys.path > > Check the output against your PYTHONPATH. > > -aj > >

1 0