Re: [Zope-dev] Standard namechooser
On Feb 11, 2008, at 10:15 AM, Aaron Lehmann wrote: Possibly instead of returning an error, it might resolve the name, and take an optional callback that performs said resolution? That way, people who have their own resolution code can easily factor it in. Or is this a case where another NameChooser should be registered? I'm going to shut up now, because I think my schitzophrenia is showing. Aaron Lehmann ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Standard namechooser
On Feb 11, 2008, at 10:06 AM, Christian Theune wrote: Hi, Aaron Lehmann schrieb: Christian, What if people are relying on those error messages to do different things? Possibly they already have normalization code they expect to come into play in this situation, which is different than yours . I see that people might be doing that, however, it seems like a bad idea to code that way. ;) Maybe. But enforcing this on others seems to cut against consenting adults. After all, how do you know that your desired resolution is the resolution for everyone? On the other hand, having to do this seems annoying, so as someone writing new code I'd consider your proposed patch a feature, rather than a bugfix. I'd be happy to declare it a feature, but I consider the existing state to not be ideal and thus it should be changed. Possibly instead of returning an error, it might resolve the name, and take an optional callback that performs said resolution? That way, people who have their own resolution code can easily factor it in. Aaron Lehmann ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Standard namechooser
Hi, Aaron Lehmann schrieb: Christian, What if people are relying on those error messages to do different things? Possibly they already have normalization code they expect to come into play in this situation, which is different than yours . I see that people might be doing that, however, it seems like a bad idea to code that way. ;) On the other hand, having to do this seems annoying, so as someone writing new code I'd consider your proposed patch a feature, rather than a bugfix. I'd be happy to declare it a feature, but I consider the existing state to not be ideal and thus it should be changed. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Standard namechooser
Christian, What if people are relying on those error messages to do different things? Possibly they already have normalization code they expect to come into play in this situation, which is different than yours . On the other hand, having to do this seems annoying, so as someone writing new code I'd consider your proposed patch a feature, rather than a bugfix. My two cents, Aaron Lehmann On Feb 11, 2008, at 9:55 AM, Christian Theune wrote: Hi, the standard name chooser makes sure that the character '+', '@' are not used in the beginning of a name and '/' is never used. When asking the name chooser to choose a name for me, I thought it would normalize those characters away, giving me a usable name. Reading the interface, there is a distiction between checking a name (and giving an error) and choosing a name (create one, maybe with a given name to start from) that is valid. I'd consider this to be a bug and change the name chooser accordingly. What do people think? Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Standard namechooser
Hi, Aaron Lehmann schrieb: On Feb 11, 2008, at 10:15 AM, Aaron Lehmann wrote: Possibly instead of returning an error, it might resolve the name, and take an optional callback that performs said resolution? That way, people who have their own resolution code can easily factor it in. Or is this a case where another NameChooser should be registered? Well, my point is that I think it's not the case, because we're really not doing anything specific. We're happy with this simple name chooser. I really think that simple default components are quite ok, but they should behave correctly. I'm still trying to find out what 'correct' is though. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zc.extrinsicreference release
Hi. Wondering if zc.extrinsicreference ought to be included in the versions.cfg. Currently it is at 0.1dev. It has been this way in the repository for about a year. Could/should it be released? Many thanks. Regards, David ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Standard namechooser
Hi, the standard name chooser makes sure that the character '+', '@' are not used in the beginning of a name and '/' is never used. When asking the name chooser to choose a name for me, I thought it would normalize those characters away, giving me a usable name. Reading the interface, there is a distiction between checking a name (and giving an error) and choosing a name (create one, maybe with a given name to start from) that is valid. I'd consider this to be a bug and change the name chooser accordingly. What do people think? Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zeo and queuecatalog conflict-resolution
You might be interested in: https://bugs.launchpad.net/zope2/+bug/143770 Joachim Schmitz wrote: Andreas Jung schrieb: --On 10. Februar 2008 18:34:54 +0100 Joachim Schmitz [EMAIL PROTECTED] wrote: What is the recommended method to make the conflict-resolution-code available to the zeo-server ? Is there a Products directive for zeo.conf ? I think it is sufficient that the Products directory is in the PYTHONPATH or available through sys.path. would something like: INSTANCE_PRODUCTS=/home/Zope/instances/waeup/Products ZODB3_HOME=/home/Zope/install/z296/lib/python PYTHONPATH=$ZODB3_HOME:$INSTANCE_PRODUCTS export PYTHONPATH INSTANCE_HOME in zeoctl do, and how can I check that it is realy effective ? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Sun Feb 10 12:00:00 2008 UTC to Mon Feb 11 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Feb 10 21:02:03 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-February/009089.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Feb 10 21:03:33 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-February/009090.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Feb 10 21:05:04 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-February/009091.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Feb 10 21:06:34 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-February/009092.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Feb 10 21:08:04 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-February/009093.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Feb 10 21:09:35 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-February/009094.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Standard namechooser
Aaron Lehmann schrieb: On Feb 11, 2008, at 10:06 AM, Christian Theune wrote: Hi, Aaron Lehmann schrieb: Christian, What if people are relying on those error messages to do different things? Possibly they already have normalization code they expect to come into play in this situation, which is different than yours . I see that people might be doing that, however, it seems like a bad idea to code that way. ;) Maybe. But enforcing this on others seems to cut against consenting adults. After all, how do you know that your desired resolution is the resolution for everyone? Sure, that's why I'm discussing it here. ;) On the other hand, having to do this seems annoying, so as someone writing new code I'd consider your proposed patch a feature, rather than a bugfix. I'd be happy to declare it a feature, but I consider the existing state to not be ideal and thus it should be changed. Possibly instead of returning an error, it might resolve the name, and take an optional callback that performs said resolution? That way, people who have their own resolution code can easily factor it in. Hmm. Sounds like a little too much engineering and not very componentish to me. Up to this point my thinking went this way: We have an interface that allows us to a) check whether a name is ok b) create a name that is ok for us, probably considering a name that we give him. The second method feels like it should never raise an error - that's what the `check` method is for. If you want to customize the behaviour, you can always create a different name chooser implementation. It doesn't have to be 100% correct for everyone, but it should avoid the 80% pitfalls and it certainly should implement the interface the way it is intended. Unfortunately the interface is a bit unspecific whether chooseName may raise an error if the given name does not conform to checkName or whether it is obligued to always pick a good one. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: [ZWeb] Re: [Zope] Zope lists in google
Josef Meile wrote: Somebody didn't like the bots to roam the archives? I have a feeling someone didn't want bots spanking some web-subversion front end that's running, but the end result is that we loose all Zope code and mailing list archives from Google :-( Yes, that's really sad. I really don't like gmane searching function :-( and google is my friend ;-) Indeed. Jens was chasing this up with the powers that be, I wonder if he's had any feedback? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: AW: [ZWeb] Re: [Zope] Zope lists in google
On Feb 11, 2008, at 15:03 , Chris Withers wrote: Josef Meile wrote: Somebody didn't like the bots to roam the archives? I have a feeling someone didn't want bots spanking some web- subversion front end that's running, but the end result is that we loose all Zope code and mailing list archives from Google :-( Yes, that's really sad. I really don't like gmane searching function :-( and google is my friend ;-) Indeed. Jens was chasing this up with the powers that be, I wonder if he's had any feedback? Since it was the weekend and no one at ZC can be expected to sit around just waiting for someone from the ZWeb list to complain it took a few days. The robots.txt file is now empty. jens ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: AW: [ZWeb] Re: [Zope] Zope lists in google
Jens Vagelpohl wrote: Since it was the weekend and no one at ZC can be expected to sit around just waiting for someone from the ZWeb list to complain it took a few days. The robots.txt file is now empty. Yay, good stuff :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
Re: [Zope] Frequent Zope crashes (Zope 2.9.8)
Hi Paul, It's certainly worth filing a bug over in launchpad about this. I wonder if this is 64-bit related? cheers, Chris Paul Brettschneider wrote: Hello, my Zope 2.9.8 instance crashes up to 6 times per hour. This is very unfortunate since the constant restarting brings performance to its knees. It runs under Linux in 64 bit mode on an AMD64 . I managed to catch two backtraces with gdb (see end of the mail). Both backtraces show a crash in cc_oid_unreferenced(ccobject *self, PyObject *oid) in persistent/cPickleCache.c: Either in line 576: v = PyDict_GetItem(self-data, oid); or in line 607: Py_DECREF((ccobject *)((cPersistentObject *)v)-cache); v and v-cache seem to point to heap: (gdb) print v $1 = (PyObject *) 0x5f8920 (gdb) print ((cPersistentObject *)v)-cache $2 = (PerCache *) 0x613620 Always called from Per_dealloc(cPersistentObject *self) in persistent/cPersistence.c in line 578: cPersistenceCAPI-percachedel(self-cache, self-oid); Is this a known issue? Thank you for any help, Paul #0 0x00436777 in PyDict_Contains () #1 0x004369ad in PyDict_GetItem () #2 0x2b56466e6f37 in cc_oid_unreferenced (self=0x2b564b71c808, oid=0x2ce4ecc0) at persistent/cPickleCache.c:576 #3 0x2b56464ded28 in Per_dealloc (self=0x2ce50050) at persistent/cPersistence.c:578 #4 0x00446bf3 in PyType_GenericAlloc () #5 0x00436bdc in PyDict_GetItem () #6 0x00446c4c in PyType_GenericAlloc () #7 0x00436bdc in PyDict_GetItem () #8 0x00446c4c in PyType_GenericAlloc () #9 0x00436bdc in PyDict_GetItem () #10 0x00446c4c in PyType_GenericAlloc () #11 0x00436bdc in PyDict_GetItem () #12 0x00446c4c in PyType_GenericAlloc () #13 0x00438ddb in _PyTrash_destroy_chain () #14 0x2b56466e772a in cc_clear (self=0x2b564b71c808) at persistent/cPickleCache.c:756 #15 0x0049f212 in _PyObject_GC_UnTrack () #16 0x0049fab5 in _PyObject_GC_New () #17 0x004bc6c8 in PyFunction_New () #18 0x004715ac in PyEval_EvalFrame () #19 0x00474f48 in PyEval_EvalCodeEx () #20 0x00472ca5 in PyEval_EvalFrame () #21 0x00472d99 in PyEval_EvalFrame () #22 0x00472d99 in PyEval_EvalFrame () #23 0x00472d99 in PyEval_EvalFrame () #24 0x00474f48 in PyEval_EvalCodeEx () #25 0x004bc293 in PyClassMethod_New () #26 0x004139f0 in PyObject_Call () #27 0x004196ee in PyClass_IsSubclass () #28 0x004139f0 in PyObject_Call () #29 0x2b5646121a1e in fast_save_leave () from /usr/lib/python2.4/lib-dynload/cPickle.so #30 0x2b5646124a4e in fast_save_leave () from /usr/lib/python2.4/lib-dynload/cPickle.so #31 0x0047453c in PyEval_EvalFrame () #32 0x00472d99 in PyEval_EvalFrame () #33 0x00472d99 in PyEval_EvalFrame () #34 0x00472d99 in PyEval_EvalFrame () #35 0x00474f48 in PyEval_EvalCodeEx () #36 0x004bc293 in PyClassMethod_New () #37 0x004139f0 in PyObject_Call () #38 0x004196ee in PyClass_IsSubclass () #39 0x00415d93 in PyObject_CallMethod () #40 0x2b56464de888 in unghostify (self=0x2de96aa0) at persistent/cPersistence.c:100 #41 0x2b56464de909 in Per_setstate (self=0x24fb740) at persistent/cPersistence.c:1125 #42 0x2b56482ebcb8 in P_getattr (self=0x2de96aa0, name=0x2aafafb0) at Persistence/_Persistence.c:108 #43 0x2b5646b80242 in Wrapper_findattr (self=0x2b61c310, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0) at Acquisition/_Acquisition.c:479 #44 0x2b5646b81031 in Wrapper_acquire (self=0x2b61cb50, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, explicit=value optimized out, containment=0) at Acquisition/_Acquisition.c:544 #45 0x2b5646b8049c in Wrapper_findattr (self=0x2b61cb50, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0) at Acquisition/_Acquisition.c:514 #46 0x2b5646b81031 in Wrapper_acquire (self=0x2b61cb90, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, explicit=value optimized out, containment=0) at Acquisition/_Acquisition.c:544 #47 0x2b5646b8049c in Wrapper_findattr (self=0x2b61cb90, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0) at Acquisition/_Acquisition.c:514 #48 0x2b5646b81031 in Wrapper_acquire (self=0x2b61c9d0, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, explicit=value optimized out, containment=0) at Acquisition/_Acquisition.c:544 #49 0x2b5646b8049c in Wrapper_findattr (self=0x2b61c9d0, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0) at Acquisition/_Acquisition.c:514 #50 0x2b5646b81031 in Wrapper_acquire (self=0x2b61c490, oname=0x2aafafb0, filter=0x0, extra=0x0, orig=0x0, explicit=value optimized out,
[Zope] Re: Frequent Zope crashes (Zope 2.9.8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Brettschneider wrote: Hello, my Zope 2.9.8 instance crashes up to 6 times per hour. This is very unfortunate since the constant restarting brings performance to its knees. It runs under Linux in 64 bit mode on an AMD64 . I managed to catch two backtraces with gdb (see end of the mail). Both backtraces show a crash in cc_oid_unreferenced(ccobject *self, PyObject *oid) in persistent/cPickleCache.c: Either in line 576: v = PyDict_GetItem(self-data, oid); or in line 607: Py_DECREF((ccobject *)((cPersistentObject *)v)-cache); v and v-cache seem to point to heap: (gdb) print v $1 = (PyObject *) 0x5f8920 (gdb) print ((cPersistentObject *)v)-cache $2 = (PerCache *) 0x613620 Always called from Per_dealloc(cPersistentObject *self) in persistent/cPersistence.c in line 578: cPersistenceCAPI-percachedel(self-cache, self-oid); Is this a known issue? Thank you for any help, Can you reproduce using the following from-scratch build? $ cd /tmp $ wget http://www.zope.org/Products/Zope/2.9.8/Zope-2.9.8-final.tgz $ tar xzf Zope-2.9.8-final.tgz $ cd Zope-2.9.8-final $ ./configure --with-python=/path/to/64-bin-python \ --prefix=/tmp/z298 make make install $ /tmp/z298/bin/mkzopeinstance.py -d /tmp/instance -u admin:123 $ /tmp/instance/bin/zopectl fg Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsIMr+gerLs4ltQ4RAlPbAJ95lNWC8M0qBkN9zS3zfdqRTtvSRACfSQj+ KzySBx/+qsJnYTmMX3UPEAM= =b509 -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] python script, from string to dictionary.
Dieter Maurer wrote:
- google for the bugs in python's
rexec and bastion modules which lead to them being deprecated...
I speak only about eval (not exec or rexec nor bastion).
In the eval world, you only have expressions.
And with the __builtins__ above, you have no builtin functions,
no classes, no types -- you have just the literals the parser
can recognize: strings, integer, float, None, lists, tuples,
dicts, generators and the typical operators on them.
I suggest you actually follow your own usual advice and do some
searching, it's never that simple, as you'll see from the bugs people
have encountered with rexec and bastion ;-)
But, for clarity and for the lazy, here's Toby's example of how to get
at some interesting classes without using aything but the exec
environment you described:
{}.__class__.__bases__[0].__subclasses__()
I know Toby wanted to keep that off-list but I think it's important that
people understand just how unsafe it is to exec anything you can't 100%
trust.
I have an addage that there's always something better than exec and I
haven't been proved wrong yet...
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
