Re: [Zope-dev] Next steps on Zope 2.6 plan
Brian Lloyd wrote: One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Hmm, these rules seem to have several thinly veiled references to my pet project. :-) I do firmly agree with the rules in spirit, but I think a little clarification/discussion is in order so it doesn't get cut without good reason. - A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 - Zope3). Agreed. I think it is important to note two things, though: 1. Creating the new, recommended installation procedure is different from gutting and replacing an existing feature, simply because we don't really *have* a recommended installation procedure right now. As currently proposed, you can still use Zope 2.6 just like you used Zope 2.5, except you'll type 'make' instead of 'python2.1 wo_pcgi.py'. 2. I've tried to keep this proposal clean enough that it can easily be brought into Z3, so that instances of Z2 and Z3 on the same system can be controlled and managed by the same software. The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind. Just to reiterate, they'll have all the time they need. The only people I see scrambling to get up to date are Zope 2.6 packagers (like myself). Perhaps a qualification is in order here, i.e. mitigation of this effect by maintaining as much backwards compatibility as possible. - Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers. My proposal will probably reduce support burdens. Just the other day, on IRC, we had to tell someone to switch away from his nicely packaged RPM version of Zope and use the source distro. So maybe this should be a qualified rule as well? Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions. I don't know if the above constitutes useful information for writing rule changes or not, but I hope it's helpful. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Next steps on Zope 2.6 plan
FWIW, I think a better Zope install is desperately necessary, and since there's a fishbowl proposal and a willing contributor (you), IMHO it's a no-brainer.. the biggest hurdle is keeping you happy and willing to write code and docs. ;-) That said, since we don't have a less centralized or formalized process in place, it will likely boil down to some sort of straw poll on the lists with Brian having veto power as to what is reasonable to shoot for for 2.6 and that will dictate which proposed features will be accepted. Fun. ;-) - Original Message - From: Matt Behrens [EMAIL PROTECTED] To: Brian Lloyd [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 7:53 AM Subject: Re: [Zope-dev] Next steps on Zope 2.6 plan Brian Lloyd wrote: One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Hmm, these rules seem to have several thinly veiled references to my pet project. :-) I do firmly agree with the rules in spirit, but I think a little clarification/discussion is in order so it doesn't get cut without good reason. - A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 - Zope3). Agreed. I think it is important to note two things, though: 1. Creating the new, recommended installation procedure is different from gutting and replacing an existing feature, simply because we don't really *have* a recommended installation procedure right now. As currently proposed, you can still use Zope 2.6 just like you used Zope 2.5, except you'll type 'make' instead of 'python2.1 wo_pcgi.py'. 2. I've tried to keep this proposal clean enough that it can easily be brought into Z3, so that instances of Z2 and Z3 on the same system can be controlled and managed by the same software. The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind. Just to reiterate, they'll have all the time they need. The only people I see scrambling to get up to date are Zope 2.6 packagers (like myself). Perhaps a qualification is in order here, i.e. mitigation of this effect by maintaining as much backwards compatibility as possible. - Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers. My proposal will probably reduce support burdens. Just the other day, on IRC, we had to tell someone to switch away from his nicely packaged RPM version of Zope and use the source distro. So maybe this should be a qualified rule as well? Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions. I don't know if the above constitutes useful information for writing rule changes or not, but I hope it's helpful. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Next steps on Zope 2.6 plan
One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Hmm, these rules seem to have several thinly veiled references to my pet project. :-) I do firmly agree with the rules in spirit, but I think a little clarification/discussion is in order so it doesn't get cut without good reason. Of course. Note that my references were not (and were not intended to be, veiled or otherwise :) knocks on your proposal or any _particular_ proposal. My point was to say that one big change should be the limit for any given feature release. This can be a helpful guideline for the future: if as a developer you know that total security rewrite is already on the list for some feature release, then you can be pretty sure that you'll have a hard fight to get some other major change into the same release. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: more on the segfault saga
Ok, got some data on using this patches. First of all, for those following, these patches don't seem to work well if starting Zope as root, cause gdb will be started as the user Zope turns to, and this gdb won't be able to attach to a root started process, even if it's dropped it's privileges. Now, the gdb.cmd script that comes with it is not being able to make the trace_dump file for some reason. Below are the urls to Zope's stdout/err in 2 segfault instances, one generated by an external method that calls cprof.segfault() and another that was generated by normal load. http://www.ibccrim.org.br/imagens/data-temp/stdout-20020321-ext-method-segfault http://www.ibccrim.org.br/imagens/data-temp/stdout-20020321-natural-segfault The 'No such process' message might be caused by the process dying while trying to generate the file in the trace_dump() call, but I don't know why would that be. I'll see if I can install another Zope instance where it all belongs to another user, so that we can rule out lack of permissions for this problem. On Tue, 2002-03-19 at 18:10, Matthew T. Kromer wrote: Leonardo Rochael Almeida wrote: The official unofficial Zope place on irc is #zope at irc.openprojects.net. Lots of cool and very knowledgeable people hang out there. OK, I put up a set of patches and a rather frazzled looking README for a profiler patch to Python at http://www.zope.org/Members/matt You want the C profiler patch; you have to build your OWN python 2.1.2 and it will probably only work under Linux -- dont bother with Windows, parts of the code use mmap() for speed and Windows doesn't provide mmap. There's a README document inside that has some rather vague and minimal installation instructions. This is very definately use-at-your-own-risk stuff. I'm posting notice here because others are interested in trying to help diagnose the Zope crashing problem so this serves as a reminder of where something is as it sits in your inbox waiting for bits to decay. Here's the readme in its entirety: To activate python tracing Rebuild a clean python 2.1.2 with the two patches (included) applied. Patch 1 is for the garbage collector module, it installs a segfault handler which allows for an environment variable CRASHCMD to be present to tell python what to do in the event of a segfault. Patch 2 is a patch to ceval.c which builds in addtional tracing. The cprof module must be built; a simple make -f Makefile.pre.in PYTHON=/path/to/rebuilt/python2.1.2 will build the cprof module. Once built, test the cprof module /path/to/rebuild/python2.1.2 import cprof cprof.activate() cprof.dump(filename) and the filename specified should be created. For the curious, the pb.py program will play back the trace file to get data out of it. PATCHING ZOPE TO USE THIS Replace Zope's ZServer/PubCore/ZServerPublisher file with the included one. Patch the line that contains the gdb command to point to your rebuilt python. Copy the file gdb.cmd to where you start Zope. Copy the file cprof.so to lib/python in your Zope directory Start Zope. Wait. GDB will be invoked to gather crash data, save the gdb output if possble (keep stdout from gdb). Unfortunately, the README forgets to mention that you need to run Zope under the patched python. Whoops. -- Matt Kromer Zope Corporation http://www.zope.com/ -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] [Zope] Problem with adding importable modules
Hello all,
I originally sent this one just to the [EMAIL PROTECTED] list, but I just saw a bug report
similar to this about 2.5.b2 on the Zope collector at
http://collector.zope.org/Zope/77, so I figured I'd also submit it to you. I'm
running 2.5.0-src (see traceback below).
I have a problem regarding allowing the import of extra modules. I've found
various examples (like the Allowing Import of Modules in the Zope online
help) and a mailing list item entitled Import Libraries into Python Script
(http://lists.zope.org/pipermail/zope-dev/2001-February/009531.html), but
these aren't helping me. I'm still getting this error.
I'm trying to use the Reportlab toolkit from within a Zope script (NOT an
external method). I DON'T want to just import the whole Reportlab toolkit,
because within that toolkit there are sys and os sections with what appear
to contain very dangerous items. Therefore, I'm following more along the
lines of the help in the Zope online help. I created a folder called
MyScriptModules in $ZOPE/lib/python/Products/. The __init__.py file therein
looks like this:
-contents of __init__.py-
from Products.PythonScripts.Utility import allow_module, allow_class
from AccessControl import ModuleSecurityInfo, ClassSecurityInfo
from Globals import InitializeClass
from reportlab import platypus
from reportlab.lib import colors, enums, pagesizes, styles, units
from reportlab.pdfgen.canvas import Canvas
allow_class(Canvas)
allow_class(platypus)
allow_class(colors)
allow_class(enums)
allow_class(pagesizes)
allow_class(styles)
allow_class(units)
ModuleSecurityInfo('reportlab').declarePublic('platypus')
ModuleSecurityInfo('reportlab.lib').declarePublic('colors','enums','pagesize
s','
styles','units')
ModuleSecurityInfo('reportlab.pdfgen.canvas').declarePublic('Canvas')
-end __init__.py contents-
I only wanted to import the bare essentials of my current program and some
other classes that looked harmless but useful (like colors, enums, etc). I
first started with ReportLab by creating a shell-based python script, which
ran perfectly and created my PDF file. Now I'm porting it to Zope and I'm
getting errors. Here's a curtailed example of the script. This short
example creates the same error I'm getting in the full version of the
script:
begin sample problem script-
#___DO ALL THE IMPORTS__
from reportlab import platypus
from reportlab.lib import styles, units, pagesizes
from reportlab.pdfgen.canvas import Canvas
import string
#___END IMPORTS SECTION_
#___SET UP GLOBAL VARIABLES_
PAGE_WIDTH = pagesizes.letter[0]
PAGE_HEIGHT = pagesizes.letter[1]
txt_styles = styles.getSampleStyleSheet()
styleTITLE = txt_styles['Heading1']
#___END GLOBAL VARIABLES
return I didn't crash
---end sample problem script---
When I try to test it Zope tries to make me log in again, I do so, and it
asks me to log in repeatedly. If I finally click Cancel, it gives me
this:
--begin error condition
experienced---
Zope Error
Zope has encountered an error while publishing this resource.
Error Type: Unauthorized
Error Value: You are not allowed to access Heading1 in this context
(cut out Troubleshooting Suggestions)
Traceback (innermost last):
File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 150,
in publish_module
File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 114,
in publish
File /usr/local/Zope-2.5.0-src/lib/python/Zope/__init__.py, line 158, in
zpublisher_exception_hook
(Object: feedback)
File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 98,
in publish
File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/mapply.py, line 88,
in mapply
(Object: test.py)
File /usr/local/Zope-2.5.0-src/lib/python/ZPublisher/Publish.py, line 39,
in call_object
(Object: test.py)
File /usr/local/Zope-2.5.0-src/lib/python/Shared/DC/Scripts/Bindings.py,
line 252, in __call__
(Object: test.py)
File /usr/local/Zope-2.5.0-src/lib/python/Shared/DC/Scripts/Bindings.py,
line 283, in _bindAndExec
(Object: test.py)
File
/usr/local/Zope-2.5.0-src/lib/python/Products/PythonScripts/PythonScript.py,
line 291, in _exec
(Object: test.py)
(Info: ({'script': PythonScript instance at 8ed0008, 'context':
Folder instance at 8ecd2d0, 'container': Folder instance at 8ecd2d0,
'traverse_subpath': []}, (), {}, None))
File Script (Python), line 17, in test.py
File /usr/local/Zope-2.5.0-src/lib/python/AccessControl/ZopeGuards.py,
line 94, in guarded_getitem
Unauthorized: (see above)
--end error condition
[Zope-dev] range:min bug in ZCatalogs fo Zope 2.3.2
Hi, I have encountered a strange problem with ZCatalogs in Zope 2.3.2. We have objects having DateTime arguments effective_date and expiration_date that gets indexed in different ZCatalogs. (The index is a field index). We then tries to get all published objects that have not yet been archived: now=_.DateTime() Service.searchResults( effective_date =now, effective_date_usage='range:max' , expiration_date =now, expiration_date_usage='range:min' ) Now this works fine, until one day when result searchResults returns an empty result list which is not expected. It seems to be that some days the range:min statement doesn't work correctly. (I tried with different range:* combinations and the only thing I found not working is the range:min statement (some days). If I instead use a different value for now: now2 = _.DateTime(now.Date()) # now.Date() returns somethong like 2002/03/21 which in turn makes the now2 equal to the DateTime value 2002/03/21 00:00:000 GMT+1 (GMT+1 is my local TimeZone) Now using now2 in: Service.searchResults( effective_date =now, effective_date_usage='range:max' , expiration_date =now2, expiration_date_usage='range:min' ) will always result in a list (all though it gets quantized to midnight the resulting list will be somewhat biased). What I don't seem to understand is that DateTime() and DateTime(DateTime().Date) gets so different results. Have anyone seen something like this before? Best Regards, Johan Carlsson -- Johan Carlsson, Torped AB http://www.torped.se -- http://easypublisher.torped.se ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope] range:min bug in ZCatalogs fo Zope 2.3.2
Try to reproduce the same problem under 2.5.X. Or upgrade to 2.5.X. Andreas - Original Message - From: Johan Carlsson [Torped] [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 05:51 Subject: [Zope] range:min bug in ZCatalogs fo Zope 2.3.2 Hi, I have encountered a strange problem with ZCatalogs in Zope 2.3.2. We have objects having DateTime arguments effective_date and expiration_date that gets indexed in different ZCatalogs. (The index is a field index). We then tries to get all published objects that have not yet been archived: now=_.DateTime() Service.searchResults( effective_date =now, effective_date_usage='range:max' , expiration_date =now, expiration_date_usage='range:min' ) Now this works fine, until one day when result searchResults returns an empty result list which is not expected. It seems to be that some days the range:min statement doesn't work correctly. (I tried with different range:* combinations and the only thing I found not working is the range:min statement (some days). If I instead use a different value for now: now2 = _.DateTime(now.Date()) # now.Date() returns somethong like 2002/03/21 which in turn makes the now2 equal to the DateTime value 2002/03/21 00:00:000 GMT+1 (GMT+1 is my local TimeZone) Now using now2 in: Service.searchResults( effective_date =now, effective_date_usage='range:max' , expiration_date =now2, expiration_date_usage='range:min' ) will always result in a list (all though it gets quantized to midnight the resulting list will be somewhat biased). What I don't seem to understand is that DateTime() and DateTime(DateTime().Date) gets so different results. Have anyone seen something like this before? Best Regards, Johan Carlsson -- Johan Carlsson, Torped AB http://www.torped.se -- http://easypublisher.torped.se ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
