Re: [Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Even if we don't branch at those points, we should be tagging the freeze point any any intermediate OK, fixed that, now try again points. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
On Tuesday 18 October 2005 21:12, Mikhail Kashkin wrote: I'm also want to offer me as fresh meat in this effort. My proposition for site plan, index pages *mark*:: Hi Mikhail, the outline is nice, but contains items that we do not have already; for example it has a huge documentation section with lots of items, but none of this type of documentation exists and you cannot expect it to magically appear. Having said this, I really wish someone would take ownership in developing our zope3.org site. Unfortunately I have not heard from Uwe anymore, but someone should contact him and see what's going on. With that much interest I would hope that a steady developer group around zope3.org would form. Is that possible? IS someone willed to take the lead? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] initial checkin of cxoracleda
On Thursday 20 October 2005 11:19, Bernd Dorn wrote:
in my testcase http://svn.zope.org/cxoracleda/trunk/tests/
test_adapter.py?rev=39515view=auto
You need to bug Jim, so that this directory is part of the Zope3-Checkins
mailing list. ;-)
i need to somehow get the connection information from a property
file, is this the right way to do this
i do this like this::
import os
propFile = os.path.join(os.environ.get('HOME'),etc/zope/cxoracleda/
testproperties.py)
try:
execfile(propFile)
except:
raise Local property file not found,propFile
this is a problem i think for automated tests etc.
any sugestions ?
This is a problem. It would be easier if you add a sample configuration file
in your test directory, e.g. cxoracle/tests/configfile.py and then reference
it as follows in your test:
import os
dir = os.path.dirname(__file__)
config = os.path.join(dir, 'configfile.py')
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] simpleTraverse raises NameError?
On Sunday 23 October 2005 03:12, Stefan H. Holek wrote: So, is there or would this qualify as a bug? There is a test that seems to point to some use with regard to namespaces, but I don't see how this wouldn't work just as well with AttributeError. I definitely think this is a bug. I guess the | operator should simply also know how to deal with NameError. Stefan, it would be great if you could fix this or at least file a bug report. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tagged value handling inconsequent for interface methods and attributes and interfaces themself
On Tuesday 01 November 2005 04:27, Grégoire Weber wrote:
2005/10/24, Stephan Richter [EMAIL PROTECTED]:
class IFoo(zope.interface.Interface):
attr = zope.interface.Attribute('doc string')
ITaggedValues(attr).someVariable = value
Any comments before I spend time writing this up?
The drawback*) of this is that the adapter registry has to be in place.
*) Mostly a drawback if you only use ``zope.interface``
No it does not need to necessarily, because the __conform__ method is called
before a standard adapter lookup is made. Also, for those type of scenarios
we could have a custom adapter registry. Luckily adapter registries are
implemented in zope.interface.adapter, so no external packages would be
necessary.
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
---
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] (zope/app/cache/ram.py) class Storage's cleanup problem.
On Tuesday 01 November 2005 05:10, Simon Hang wrote: Dear all, I'm happen to find out call Storage only do cleanup when new Entry comes and do nothing when entries get from storage. So entries will be next expired if there are only read activities. I agree with your analysis and solution. If you provide a test for the fix, I'll check it in. If you cannot write a test, please add least add an issue to the issue collector. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Monday 07 November 2005 10:18, Brian Sutherland wrote: Please don't check this in yet, I want to review the problem before you do, because I think specific interfaces are just nuts unless we have a very good reason. Sure;) The guts of the issue are how to know what type of SQL the connection accepts so that sqlos can choose the right adapter for it. An interface seemed best. After thinking about it on and off for the last week, I agree now. The simplest, easiest and most effective solution are specific interfaces. *sigh* Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
On Friday 04 November 2005 11:50, Adam Groszer wrote: I think I have something for tomorrow's bug day. It is not working again. I have the current trunk and brand new instance. Could you add it to the issue collector please? Thanks! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.appsetup.bootstrap proposal
On Friday 04 November 2005 14:07, Adam Groszer wrote: I think (that may be stupid, because I'm not an expert) that the module is not 100% consistent, once it is checking on the passed folder's SiteManager (in ensureUtility) and then tries to add the utility to a maybe completely different SM (in addUtility). I propose a change to getSiteManagerDefault: def getSiteManagerDefault(root_folder): #default = zapi.traverse(folder.getSiteManager(), 'default') #package_name = '/++etc++site/default' #package = traverse(root_folder, package_name) package = traverse(root_folder.getSiteManager(), 'default') return package After that the module could be used even on sub-sites. +1 for the change. Please write a test and check that in. If you cannot check it in, put the fix and the test into the issue collector please. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] conflict error in configuration file
On Sunday 06 November 2005 03:23, baiju m wrote: I am developing small Zope3 app using Zope 3.1, today when I installed Zope svn trunk, I got two conflict errors. I used a 'title' which is same as that used in zwiki (addMenuItem directive). and 'name' in addform directive. The problem here is that menu items are named adapters and are thus discriminated by their name. In the case of menu items this is suboptimal. I agree with you that you should be allowed to have several menu items with the same name. Your fix below is definitely unacceptable, because it fixes the issue and the wrong place. The real fix would be to not make the menu item name the same as the title. It would be great, if you could fix the issue; if you do not have the time or skills, please file a bug issue, at least. Thanks a lot! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Deleting utilities in site management doesn't work correct
On Friday 11 November 2005 12:00, jürgen Kartnaller wrote: I could now manage to have a relatively simple test (see attached file). No file attached in my E-mail. :-( I also found and fixed some other problems I encountered with the utility registration. Can you please have a look at the test implementation and let me know if this look ok. This test will not work with the current implementation of the SiteManagementView ! I already fixed some problems in my sandbox. Problems solved : - adding a utility without name - renaming utilities to a name another already renamed utility had - deleting more than one utility - better message support - show the message at the utility not just on top of the page - show UserError exception as message Sounds very exciting! :-) Thanks a lot for your work! I will also review your file, once I get it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Deleting utilities in site management doesn't work correct
On Saturday 12 November 2005 07:12, jürgen Kartnaller wrote: Ups, sorry here is the attachment. Very nice work! Check it in! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Stephan Richter wrote: On Tuesday 18 October 2005 21:12, Mikhail Kashkin wrote: I'm also want to offer me as fresh meat in this effort. My proposition for site plan, index pages *mark*:: Having said this, I really wish someone would take ownership in developing our zope3.org site. Unfortunately I have not heard from Uwe anymore, but someone should contact him and see what's going on. With that much interest I would hope that a steady developer group around zope3.org would form. Is that possible? IS someone willed to take the lead? Hi Stephan, And I agree to help zope3.org group. I can spend 2-3 hours everyday. Where to start? -- Regards, Netlander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zopeorg-webmaster] Zope3 pages seem woefully outdated
Forwarding ... related to the current [ zope3 website report? ] thread Toni Mueller wrote: Hello, I find that most pages about Zope3 end sometime mid 2004. A lot has happened in the meantime, and I'd like to see updated material on the site. Since I'm rather new to Zope3, I feel not qualified to produce useful content for the site, but having material that old is probably not the best way to make Zope3 take off, as intended. If you have suggestions on how to proceed, or what to do (technically, I find the whole site lacking, and significantly below Zope's capabilities), I'm very much open to any suggestions you might have. Thank you for listening! Kind Regards, --Toni++ ___ Zopeorg-webmaster mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zopeorg-webmaster Michael -- http://zope.org/Members/d2m http://planetzope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Extrinsic references
We have a *simple* facility for managing references between objects extrinsically. See: http://svn.zope.org/Sandbox/zc/extrinsicreference/extrinsicreference.txt?view=markup If there is sufficient interest, we plan to move this (tiny) project to the zope repository. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://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] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
Stephan Richter wrote: On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Actually, I said we ought to be ready for the first beta by Nov 1. :) Even if we don't branch at those points, we should be tagging the freeze point any any intermediate OK, fixed that, now try again points. Absolutely. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. No, it wouldn't. In my strongly held opinion, you should never depend on a trunk or branch unless the people checking in there are running *your* tests before a checkin. A bug fix I made earlier this week actually broke a Five test. Depending on revisions, which you update frequently, provides important stability. The person who updates the revision can first make sure all their tests pass, addressing any issues before checking in. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://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] Yet Another Relations (aka Reference) Engine...
Helmut Merz wrote: Am Freitag, 11. November 2005 18:00 schrieb Jean-Marc Orliaguet: I was thinking more about the policy of assigning unique ids to objects in a relation. It's the application that really should decide about that policy. in fact the unique ids aren't assigned to the objects (the objects aren't touched at all) by the IntIds utility - if you have registered a local IntIds utility they are just created in the utility driven by the IObjectAdded event. So this IntIds stuff should not interfere with anything else and the application should not be concerned at all about it. The good thing about IntIds is that it leaves the objects untouched, the bad thing is that it creates a hard coupling between the integer id that is used to *refer* to the object and the key that is used to *represent* the object in the relation. These are really two different aspects. In cpsskins when objects are set in relation, it is the application's responsibility to tell the engine how objects will be identified in the relation, i.e. with a unique id (IntIds), or with a URI or a with a name (that may be share between several objects) ... The relation engine then stores this key as well as an internal reference to the object. so for each object put in relation we have: - a key (used by the application to query the engine) - a reference to the object (used internally by the relation engine to get the object) the application only sees the keys until the objects get dereferenced. But no 1:1 mapping between the key and the object is imposed by any external IntIds utility. Which make it possible to ask the engine: give me all the portlets associated to the 'left' slot even though the 'left' slot is materialized in more than one instance. In your implementation only objects that are identified uniquely can be put in relation, and it doesn't seem to be a design choice other than a limitation imposed by the catalog. http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/j mo -perspectives/storage/relations.py I read this, and it indeed gave me the impression that it might be a not so bad idea to use a catalog ;-) well, you haven't written the catalog indexes yet :-) I needn't because I just use the FieldIndex from zope.index. I understand, but the idea is to index relations, not simply the references between in the objects put in relation. My impression is that you are thinking of a reference engine rather than a relation engine with the difference compared to the Archetype's engine that references are stored outside the objects. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[4]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
Hello Stephan, done that, it's issue No 485 Saturday, November 12, 2005, 12:54:21 PM, you wrote: SR On Friday 04 November 2005 11:50, Adam Groszer wrote: I think I have something for tomorrow's bug day. It is not working again. I have the current trunk and brand new instance. SR Could you add it to the issue collector please? SR Thanks! SR Regards, SR Stephan -- Best regards, Groszer Adam -- Quote of the day: A day without sunshine is like night. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet: The good thing about IntIds is that it leaves the objects untouched, the bad thing is that it creates a hard coupling between the integer id that is used to *refer* to the object and the key that is used to *represent* the object in the relation. These are really two different aspects. In cpsskins when objects are set in relation, it is the application's responsibility to tell the engine how objects will be identified in the relation, i.e. with a unique id (IntIds), or with a URI or a with a name (that may be share between several objects) ... The relation engine then stores this key as well as an internal reference to the object. so for each object put in relation we have: - a key (used by the application to query the engine) - a reference to the object (used internally by the relation engine to get the object) the application only sees the keys until the objects get dereferenced. But no 1:1 mapping between the key and the object is imposed by any external IntIds utility. Which make it possible to ask the engine: give me all the portlets associated to the 'left' slot even though the 'left' slot is materialized in more than one instance. Hm, I'm not sure I understand - so it's not the object (more precisely: its unique id) that's indexed but some value provided by the object - so this is indeed some sort of an attribute that's indexed. This I would prefer to solve using relation objects that explicitly handle additional attributes (provided by the objects that are connected by the relation) that may be indexed *in addition* to the unique ids. Or let's see this way: The keys (unique ids in the standard implementation) are retrieved by an adapter to the relation class (providing IIndexableRelation) so this adapter could provide something else if necessary. In your implementation only objects that are identified uniquely can be put in relation, and it doesn't seem to be a design choice other than a limitation imposed by the catalog. Yes, it is a limitation of the default implementation but I'm still not sure it is bad, and it can be overcome easily. http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches /j mo -perspectives/storage/relations.py I read this, and it indeed gave me the impression that it might be a not so bad idea to use a catalog ;-) well, you haven't written the catalog indexes yet :-) I needn't because I just use the FieldIndex from zope.index. I understand, but the idea is to index relations, not simply the references between in the objects put in relation. ACK My impression is that you are thinking of a reference engine rather than a relation engine Maybe I just don't see the difference... (There is one, of course, but I doubt it is really of relevance in a practical context. ) Helmut ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope/trunk/lib/python/ use a specific revision of the Zope 3 trunk for now until we have some sort of tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Friday 11 November 2005 12:15, Tres Seaver wrote: Philipp von Weitershausen wrote: Log message for revision 40048: use a specific revision of the Zope 3 trunk for now until we have some sort of tag available (e.g. a Zope 3.2 beta tag). We should have cut a Zope3-3.2 beta tag on the day of the feature freeze, so that release / stabilization activities could proceed without leaving the trunk frozen. In fact, I thought we had committed to do first beta for 2.9 and 3.2 on 1 November. Even if we don't branch at those points, we should be tagging the freeze point any any intermediate OK, fixed that, now try again points. Yeah, but the bug day was a big flop for both Zope 2 and Zope 3, so Andreas and I (and even with Jim's approval) decided not to release. I also will not cut a branch until more bugs have been fixed, so that I lower the bar for bug fixers and force people to work on bugs not features. I don't understand avoiding making a beta because of known bugs -- beta is not the same as release candidate, and doesn't imply that there are no known issues. I believe that leaving the trunk frozen for a substantial length of time has a chilling effect on the health of the project, which *contributes* to the length of the beta period, rather than shortening it. The poster child for my argument is the 3.1 release cycle, which lasted for 9 months! BTW, I think that Philipp did the right thing. Depending on a specific revision is fine, though pointing to the trunk right now would work too, since it is feature frozen. Depending on numeric revision IDs obscures intent: if we aren't going to make a release branch, and tags from it, then we need at least to be creating alpha-ish tags from the trunk, and having dependents use those tags. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDdjxJ+gerLs4ltQ4RAhRqAJ4+5OobRv4YLKrLtMSgwnRnAklxlACglTaC E8AxPKU+/xyxUl7m/MZe0A0= =QQxl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...
Helmut Merz wrote: Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet: My impression is that you are thinking of a reference engine rather than a relation engine Maybe I just don't see the difference... (There is one, of course, but I doubt it is really of relevance in a practical context. ) Helmut A relation contains several references: a relation between A, B and C involves 7 references: A with itself B with itself C with itself A with B B with C C with A A with B with C But a set of references don't make explicit relations, unless the application know how to interpret the references. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Changing zope.app.rdb to better support sqlos
On Sat, Nov 12, 2005 at 06:53:23AM -0500, Stephan Richter wrote: On Monday 07 November 2005 10:18, Brian Sutherland wrote: Please don't check this in yet, I want to review the problem before you do, because I think specific interfaces are just nuts unless we have a very good reason. Sure;) The guts of the issue are how to know what type of SQL the connection accepts so that sqlos can choose the right adapter for it. An interface seemed best. After thinking about it on and off for the last week, I agree now. The simplest, easiest and most effective solution are specific interfaces. *sigh* Yeah, I just found zope.schema.interfaces and now understand your sigh. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] (zope/app/cache/ram.py) class Storage's cleanup problem.
Thanks Stephan,
Here is the test:(test_ramcache.py)
class TestStorage(TestCase):
def test_getEntry(self):
--snipped--
def test_getEntry_do_cleanup(self):
from zope.app.cache.ram import Storage
s = Storage(cleanupInterval=300, maxAge=300)
object = 'object'
key = ('view', (), ('answer', 42))
value = 'yes'
s.setEntry(object, key, value)
s._data[object][key][1] = time() - 400
s.lastCleanup = time() - 400
try:
s.getEntry(object, key)
except KeyError:
pass
else:
raise cleanup not called
def test_setEntry(self): --snipped--
On 11/12/05, Stephan Richter [EMAIL PROTECTED] wrote:
On Tuesday 01 November 2005 05:10, Simon Hang wrote: Dear all, I'm happen to find out call Storage only do cleanup when new Entry comes and do nothing when entries get from storage. So entries will be next
expired if there are only read activities.I agree with your analysis and solution. If you provide a test for the fix,I'll check it in. If you cannot write a test, please add least add an issueto the issue collector.
Regards,Stephan--Stephan RichterCBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)Web2k - Web Software Design, Development 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] branched Zope 2.9
FYI (this is mostly for the benefit of the Five folks), I've created a Zope 2.9 branch from the trunk as of about 10 minutes ago. This branch is frozen for feature work; it may need some changing of externals to reflect what we want the initial version of Zope 3 that we want 2.9 to ship with. I don't know what that version is, so this is a note to say that if these externals changes get made on the Zope 2 trunk, please also make them on the 2.9 branch. - C ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] branched Zope 2.9
--On 12. November 2005 22:08:38 -0500 Chris McDonough [EMAIL PROTECTED] wrote: FYI (this is mostly for the benefit of the Five folks), I've created a Zope 2.9 branch from the trunk as of about 10 minutes ago. This branch is frozen for feature work; it may need some changing of externals to reflect what we want the initial version of Zope 3 that we want 2.9 to ship with. I don't know what that version is, so this is a note to say that if these externals changes get made on the Zope 2 trunk, please also make them on the 2.9 branch. I would have created the 2.9 branch in case the current trunk would be ready to branch. At least one week ago there were unresolved issues (with zpkg I think) that deferred the 2.9 release (scheduled for last Monday). So in general what is the current state of the remaining work to get 2.9b1 out to the people? Andreas pgpdCmBJ7gtTt.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
