[Zope3-dev] Re: Eggs for deprecated packages
Baiju M wrote: There are few deprecated packages in zope.app namespace, should we create individual eggs for those packages ? -1 What about creating a single egg with all deprecated packges ? +1 :) If so, what should be the name of that all-deprecated-in-one package name ? We don't need to decide a *package name* (the package names are clear), we need to decide a name for the *egg*. Often the name of the egg and the name of the package are the same, but when an egg contains several packages, it doesn't have to be. Here is some names: zope.app -1 if that's the only thing the 'zope.app' egg would contain. zope.app.deprecated zope.app.obsolete zope.app.back35 -1 to all. Every one of those names suggest that they contain a package with that name, which they don't. How about ZopeAppBBB35 ? By the way, I've seen that you guys are creating eggs of some stuff that's really meant for spring cleaning (e.g. zope.app.externaleditor, zope.app.css off of the top of my head). Instead of linking the external to the Zope 3 tree, how about actually *moving* this stuff *out* of the Zope 3 tree into their egg? Note that this stuff has never been part of a Zope 3 release anyway. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] bit puzzled with directDelivery+smtpMailer
Hello, I'm trying to catch somehow the exception that's coming when the SMTP server IP address is misconfigured or the SMTP server is not responding. My problem is that the sending works using the transaction manager. That means the exception comes after File U:\zope\svn_zope33\src\zope\publisher\publish.py, line 138, in publish publication.afterCall(request, obj) File U:\zope\svn_zope33\src\zope\app\publication\browser.py, line 78, in afterCall super(BrowserPublication, self).afterCall(request, ob) File U:\zope\svn_zope33\src\zope\app\publication\zopepublication.py, line 167, in afterCall txn.commit() That means I don't have a big chance to catch it in my app. Using queuedDelivery might be a solution, but I still don't have too many chances to give feedback of the error. There is a IMailErrorEvent, and IMailSentEvent but they don't seem to be used. Obviously they would be fired in the middle of tpc_finish. Any ideas, pointers? -- Best regards, Groszer Adam -- Quote of the day: The reports of my death are greatly exaggerated. - Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Disabling the Zope 3 Collector today
On Mar 29, 2007, at 8:16 AM, Philipp von Weitershausen wrote: Jim Fulton wrote: Assuming that I can figure out how to do so, I'm going to disable the Zope 3 collector today in preparation for switching to Launchpad. To make things clearer for the people out there, would it be possible to set up a warning incl. URL to the new bugtracker on the collector front page and/or a redirect to launchpad? I was going to set up a redirector to launchpad. I don't have time to figure out how to redirect individual issue URLs. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: IKeyReference for files
Christian Theune wrote: [snip] Right. I'm not sure whether I missed anything, but I don't quite have your whole use case on my radar. The use case is basically that people can use Zope 3 off-line, working on an SVN checkout. They then commit (through a UI) their changes, and resync with the central repository. This means that SVN is going to change data on the filesystem. Blobs have the advantage that they can assume to be the only source of changes to the physical storage location. Having changes to a (cached) data structure from the outside is always troublesome. Indeed. It's central to the use case though. Anyway, I hope that this is solvable with some inspection of SVN logs. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] The Zope3 Collector has been moved to launchpad.
New bugs can be filed at: https://bugs.launchpad.net/zope3/+filebug Users can view their personal bugs at: https://bugs.launchpad.net/~USER Using the menu on the left, they can pick between assigned, reported and subscribed bug reports (in future, the page will default to showing all bugs related to the user). Old URLs, such as http://www.zope.org/Collectors/Zope3-dev and http:// www.zope.org/Collectors/Zope3-dev/###, where ### is an old collector issue number redirect to the corresponding locations in Launchpad. Much thanks to James Henstridge and the the Launchpad team for making this happen! Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The Zope3 Collector has been moved to launchpad.
Am Donnerstag, den 29.03.2007, 11:12 -0400 schrieb Jim Fulton: New bugs can be filed at: https://bugs.launchpad.net/zope3/+filebug Users can view their personal bugs at: https://bugs.launchpad.net/~USER Using the menu on the left, they can pick between assigned, reported and subscribed bug reports (in future, the page will default to showing all bugs related to the user). Old URLs, such as http://www.zope.org/Collectors/Zope3-dev and http:// www.zope.org/Collectors/Zope3-dev/###, where ### is an old collector issue number redirect to the corresponding locations in Launchpad. Much thanks to James Henstridge and the the Launchpad team for making this happen! Yay! -- gocept gmbh co. kg - forsterstraße 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] bit puzzled with directDelivery+smtpMailer
Hi, On Thu, Mar 29, 2007 at 01:31:12PM +0200, Adam Groszer wrote: I'm trying to catch somehow the exception that's coming when the SMTP server IP address is misconfigured or the SMTP server is not responding. My problem is that the sending works using the transaction manager. That means the exception comes after File U:\zope\svn_zope33\src\zope\publisher\publish.py, line 138, in publish publication.afterCall(request, obj) File U:\zope\svn_zope33\src\zope\app\publication\browser.py, line 78, in afterCall super(BrowserPublication, self).afterCall(request, ob) File U:\zope\svn_zope33\src\zope\app\publication\zopepublication.py, line 167, in afterCall txn.commit() That means I don't have a big chance to catch it in my app. That's a feature. You don't want to send emails about changes made in transactions that were later aborted. In particular, when you encounter ZODB ConflictErrors a couple of times, you don't want three copies of the same email to be sent. Unfortunately, that means the actual sending must be done in the second phase of the two-phase commit, and it is not supposed to ever fail at that point. That makes directDelivery unsuitable for production use. Using queuedDelivery might be a solution, but I still don't have too many chances to give feedback of the error. There is a IMailErrorEvent, and IMailSentEvent but they don't seem to be used. Ouch. I do not remember why the events were never fully implemented. Obviously they would be fired in the middle of tpc_finish. Sending events is the same as running arbitrary code. That's a bad thing to do during transaction commit. There was some discussion (years ago) that the transaction mechanism should acquire a way to register some callback for code that should be run in a new transaction, after the current one is committed. I do not remember how that discussion ended. Any ideas, pointers? zope.sendmail could use some loving care and attention. For example, the queued delivery thread will loop forever trying to deliver a message with an ill-formed recipient address once every three seconds. In the meantime, this seems to work adequately: use queuedDelivery, and send a test message after depoying the application. If it doesn't come through, check the error logs. Note also that if the nearest SMTP server accepts an email, that does not guarantee delivery. We've hooked up incoming mail to a bounce message processor in one of our Zope 3 apps that matches message IDs in bounce messages with IDs of sent emails and can take appropriate action. Marius Gedminas -- I would suggest re-naming rmbdd(). I _assume_ that dd stands for data dependent, but quite frankly, rmbdd looks like the standard IBM we lost every vowel ever invented kind of assembly lanaguage to me. -- Linus Torvalds signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in zope.testing trunk Windows 2000 zc-bbwin5
The Buildbot has detected a failed build of zope.testing trunk Windows 2000 zc-bbwin5. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 764 Blamelist: andreasjung,baijum,ctheune,darrylcousins,dobe,fdrake,jacobholm,jim,mj,philikon,rafrombrc,schwendinger,shh,srichter BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Eggs for deprecated packages
Jim Fulton wrote: On Mar 29, 2007, at 6:30 AM, Baiju M wrote: Hi, There are few deprecated packages in zope.app namespace, should we create individual eggs for those packages ? Yes. What about creating a single egg with all deprecated packges ? -1. We should be able to create the deprecated eggs once and forget about them. One possible benefit of having all deprecated things grouped somehow (perhaps not necessarily in one egg, what about having a BBB virtual egg that has dependencies on all the deprecated things?) is that it makes it easier for developers to test the effects of deprecation on their code. For example, the standard Zope 3 distribution could come with this egg not installed or not activated. If your code breaks on upgrade, you try to install/activate the deprecated egg, in which case you know you'll need to do something about your code, soonishly. Alternatively, it comes installed but you try to remove it to see if your package will survive the next version upgrade. We do similar things with skins in Plone, having a skin layer called plone_deprecated. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
Lennart Regebro wrote at 2007-3-28 18:25 +0200: On 3/27/07, Dieter Maurer [EMAIL PROTECTED] wrote: However, this approach is only efficient when the sort index size is small compared to the result size. Sure. But with incremental searching, the result size is always one, right? ;-) No. You want to have one (the best one) hit from a (potentially) large set of hits. The size of this set is essential whether or not a sort index is efficient. The principle is like this: Let S be the hit set. Assume you sort index consists of values i1 i2 and use D(i) for the set of documents indexed under i, Then D(i1) intersect S preceeds D(i2) intersects S preceeds D(i3) intersects S, etc in the result ordered by the index i. If the index size is small compared to S (and if we assume the hits are uniformly distributed over the indexed values), then each intersection can determine (on average) a significant amount of sorted hits. You can efficiently determine the first hits. Assume on the other hand that S contains a single element and that the index is large, then almost all intersections are a vaste of time (as the result is the empty set). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] bit puzzled with directDelivery+smtpMailer
Hi, Am Donnerstag, den 29.03.2007, 21:37 +0300 schrieb Marius Gedminas: Hi, On Thu, Mar 29, 2007 at 01:31:12PM +0200, Adam Groszer wrote: I'm trying to catch somehow the exception that's coming when the SMTP server IP address is misconfigured or the SMTP server is not responding. My problem is that the sending works using the transaction manager. That means the exception comes after File U:\zope\svn_zope33\src\zope\publisher\publish.py, line 138, in publish publication.afterCall(request, obj) File U:\zope\svn_zope33\src\zope\app\publication\browser.py, line 78, in afterCall super(BrowserPublication, self).afterCall(request, ob) File U:\zope\svn_zope33\src\zope\app\publication\zopepublication.py, line 167, in afterCall txn.commit() That means I don't have a big chance to catch it in my app. That's a feature. You don't want to send emails about changes made in transactions that were later aborted. In particular, when you encounter ZODB ConflictErrors a couple of times, you don't want three copies of the same email to be sent. Unfortunately, that means the actual sending must be done in the second phase of the two-phase commit, and it is not supposed to ever fail at that point. At least partially untrue. It doesn't have to be done in the second phase. You can do it in the first phase and make your data manager have a very low sort key (e.g. a magic key that is lower than anything else) so it will always get vote() as last. Unfortunately controlling this isn't easy and doesn't seem to be intended to be controlled past the fact that the sort keys should be stable. That makes directDelivery unsuitable for production use. True in this incarnation. Using queuedDelivery might be a solution, but I still don't have too many chances to give feedback of the error. There is a IMailErrorEvent, and IMailSentEvent but they don't seem to be used. Ouch. I do not remember why the events were never fully implemented. Obviously they would be fired in the middle of tpc_finish. Sending events is the same as running arbitrary code. That's a bad thing to do during transaction commit. There was some discussion (years ago) that the transaction mechanism should acquire a way to register some callback for code that should be run in a new transaction, after the current one is committed. I do not remember how that discussion ended. Any ideas, pointers? zope.sendmail could use some loving care and attention. For example, the queued delivery thread will loop forever trying to deliver a message with an ill-formed recipient address once every three seconds. In the meantime, this seems to work adequately: use queuedDelivery, and send a test message after depoying the application. If it doesn't come through, check the error logs. Note also that if the nearest SMTP server accepts an email, that does not guarantee delivery. We've hooked up incoming mail to a bounce message processor in one of our Zope 3 apps that matches message IDs in bounce messages with IDs of sent emails and can take appropriate action. MailDropHost could be useful to talk to. It's a good tool in Zope-2-Land. -- gocept gmbh co. kg - forsterstraße 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.testing/trunk/setup.cfg This file is a recipe for bad releases
Jim Fulton wrote: Log message for revision 73922: This file is a recipe for bad releases Changed: D zope.testing/trunk/setup.cfg I am asking for a resolution here, do we want this file in svn for other packages ? In my experience I found this file is not required. To make a release with svn revision number just get the number from 'svn info' and copy-paste it in setup.py, then 'buildout setup . sdist' I agree with Jim says in the log message. Yes, it's YAGNI ! Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Problem when using custom importer
Hi,
I ran into a bit of a strange problem recently while using a custom
importer (installed by reassigning __builtin__.__import__). The first
thing my custom importer does is call the original __import__ to get the
module being imported from. What was strange is that when I used it to
import Zope code it blew up (in the call to the original importer)
complaining that 'zope.app.layers.zope.app.rotterdam' couldn't be
imported. I'm not sure of this, but am wondering if the problem is
because the check at zope/configuration/config.py:184 fails because my
importer adds a layer to the call stack. The check is:
if sys.exc_info()[2].tb_next is not None:
# ImportError was caused deeper
raise
The following patch has solved the problem for me:
Index: src/zope/app/component/back35.py
===
--- src/zope/app/component/back35.py(revision 73358)
+++ src/zope/app/component/back35.py(working copy)
@@ -774,7 +774,7 @@
try:
value = self.context.resolve('zope.app.layers.'+name)
-except (ConfigurationError, ValueError), v:
+except (ImportError, ConfigurationError, ValueError), v:
try:
value = self.context.resolve(name)
except ConfigurationError, v:
I'm not sure it's the right fix but thought I'd post it here anyway.
Thanks,
J.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
