- Zope-Dev - Zope lists

Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
by Jim Fulton 27 May '04

27 May '04

Casey Duncan wrote: > On Fri, 21 May 2004 09:07:24 -0400 > Jim Fulton <jim(a)zope.com> wrote: > > >>Jim Fulton wrote: >> >>>I've posted two proposals: >>> >>> http://dev.zope.org/Zope3/TALESPathExpressionAdapters >>> >>>Proposes a mechanism for easily using adapters in TALES expressions. >>> >>> http://dev.zope.org/Zope3/ZPTVariableNamespaces >>> >>>proposes a mechanism for qualifying names defined in TAL and used in >>>TALES expressions. >> >>Based on initial comments, I've retracted ZPTVariableNamespaces and >>updated: >> >> http://dev.zope.org/Zope3/TALESPathExpressionAdapters >> >>I've thrown out a few more spellings for adapter use: >> >> ob->adaptername context->dc/title > > > Hmm, C style, kinda nice, except the use of angle brakets might make > like difficult. ">" is not a problem. "<" would be a probkem. > It really is hard for me to see the intended order of > execution of this as well. It reads "context to dublin core, get title". That's exactly right. The order, left to right, is very simple. The problem with: (dc)context/title is that the order is: skip one, right to left, then left to right. The order is more complicated, except that there is an alternative left to right interpretation ... > Having dublin core go first makes more sense to me so it would read > "with the dublin core of context, get title". So, here you thinking of this as: start with the dublin core protocol adapt it from context get title ... >>One disadvantage I see with the cast notation is that it's >>a bit jarring in: >> >> a/b/(adapter)c/d >> >>as the adapter is applied to a/b/c. The order just doesn't >>seem quite right. > > > It's all in the eye of the beholder I guess. This says to me "d of c > (modified by adapter) of b of a". Wow :) But this seems wrong. It's really "(c of b of a) modified by adapter". Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

{Spam?} Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
by Steve Alexander 27 May '04

27 May '04

>>Of course, Steve suggested: >> >> ob:adaptername context:dc/title > > > This really doesn't make sense. To me it reads "In the namespace of > context get the title of dublin core". I'm not reading ":" as having anything to do with namespaces. Rather, I see '/' as the "traverse" operator, and ":" as the "adapt" operator. -- Steve Alexander

3 2

[Python 2.3.4c1] nasty LinuxThread problem not solved
by Dieter Maurer 26 May '04

26 May '04

Hello Tim, I just checked that Python 2.3.4c1 does not yet fix our LinuxThread-Crash problem -- the problem that lets a multi-threaded application enter a curious state when one on the threads crashes. And this despite the patch for this problem in Python's collector... Unfortunately, I am no "python-dev" subscriber. Can you check please whether this patch has a chance to become part of the official Python 2.3.4. If not, we would be forced to maintain our own Python version as Python's current crashing behaviour with LinuxThreads is unacceptable. -- Dieter

5 12

Zope threads on 2.7.0, python 2.3.3
by Heimo Laukkanen 26 May '04

26 May '04

Hi, I am hitting my head agains wall - and witnessing strange behaviour, where after time most of load focuses only to one thread. I am not sure what is the cause of this, but so far we have seen different things before load has concentrated to one single thread. After reading thread: http://www.gossamer-threads.com/lists/zope/dev/24230?page=last I started to wonder whether that signalling behaviour is also a cause for our problems - since we are running Debina linux without NPTL ( Linux 2.4.26 #1 SMP Thu Apr 22 11:16:14 EEST 2004 i686 unknown ). When zope is started, it nicely starts multiple threads and when tested with ab - each thread gets their share of the work. We saw in event log previously exceptions that were never caught - and thought if those were the source of the problem. Eventhough we added ugly try catch code around this problematic code - we still notice load concentration to this one thread. I will try to go and look with gdb those no longer working threads - but would like to know if anyone could give any pointers on what to look for or what to check. -huima

4 9

Re: [Zope3-dev] Re: SVN: Zope3/trunk/functional_tests/ Remove unused directory.
by Fred Drake 26 May '04

26 May '04

On Wednesday 26 May 2004 08:42 am, Philipp von Weitershausen wrote: > That works for me too, but please *above* the diff. Yes; I should have been more clear and said *immediately* following the commit message. > No, the CVS should stay in there to tell them apart, for the very same > reason you stated (patches in both CVS and svn). Without the 'SVN:', it > will still be unique. I would even argue that it would make it visually > easier. Right now, my email client lists a lot of: Ok; like I said, I don't feel very strongly about this. > Sure. I'm not saying that we should convert everything *right* now, but > moving relatively independent stuff makes sense, IMO. I'm not suggesting > to move CMF or something else with a gazillion branches... Cool. zpkg is a good candidate, since it's not shared with other projects, it's a stand-alone tool. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation

1 0

Read-only root database doesn't work ... bug or feature?
by Paul Winkler 26 May '04

26 May '04

I'm trying to figure out how to mount my main storage read-only with zope 2.7.0. I'm starting to suspect that it's impossible. I tried a few things below.... --------------------------------------------- ATTEMPT #1. I find this in the zope.conf examples: # Directive: read-only-database # # Description: # This causes the main Zope FileStorage-backed ZODB to be opened in # read-only mode. # # Default: off # # Example: # # read-only-database on ... so I uncomment that line and restart. Zope starts OK but the database is evidently still writeable, I can still change anything. Is this a bug in the zope.conf examples, or a bug in zope? ------------------------------------------------- ATTEMPT #2. Apparently there is another read-only flag within each database config section. So, I try that. In my zope.conf: <zodb_db main> # Main FileStorage database cache-size 20000 mount-point / <filestorage> path $INSTANCE/var/Data.fs read-only on </filestorage> </zodb_db> When I start with this config, zope dies during product initialization which apparently wants to commit: ------ 2004-05-19T19:08:10 ERROR(200) Zope Couldn't install Formulator Traceback (most recent call last): File "/home/pw/Zope-2.7.0/lib/python/OFS/Application.py", line 785, in install_product get_transaction().commit() File "/home/pw/Zope-2.7.0/lib/python/ZODB/Transaction.py", line 232, in commit self._commit_begin(jars, subjars, subtransaction) File "/home/pw/Zope-2.7.0/lib/python/ZODB/Transaction.py", line 340, in _commit_begin jar.tpc_begin(self) File "/home/pw/Zope-2.7.0/lib/python/ZODB/Connection.py", line 692, in tpc_begin self._storage.tpc_begin(transaction) File "/home/pw/Zope-2.7.0/lib/python/ZODB/BaseStorage.py", line 142, in tpc_begin raise POSException.ReadOnlyError() ReadOnlyError Traceback (most recent call last): File "/home/pw/Zope-2.7.0/lib/python/Zope/Startup/run.py", line 49, in ? run() File "/home/pw/Zope-2.7.0/lib/python/Zope/Startup/run.py", line 19, in run start_zope(opts.configroot) File "/home/pw/Zope-2.7.0/lib/python/Zope/Startup/__init__.py", line 51, in start_zope starter.startZope() File "/home/pw/Zope-2.7.0/lib/python/Zope/Startup/__init__.py", line 230, in startZope Zope.startup() File "/home/pw/Zope-2.7.0/lib/python/Zope/__init__.py", line 46, in startup _startup() File "/home/pw/Zope-2.7.0/lib/python/Zope/App/startup.py", line 93, in startup OFS.Application.initialize(application) File "/home/pw/Zope-2.7.0/lib/python/OFS/Application.py", line 279, in initialize initializer.initialize() File "/home/pw/Zope-2.7.0/lib/python/OFS/Application.py", line 306, in initialize self.install_products() File "/home/pw/Zope-2.7.0/lib/python/OFS/Application.py", line 553, in install_products return install_products(app) File "/home/pw/Zope-2.7.0/lib/python/OFS/Application.py", line 584, in install_products folder_permissions, raise_exc=debug_mode) File "/home/pw/Zope-2.7.0/lib/python/OFS/Application.py", line 785, in install_product get_transaction().commit() File "/home/pw/Zope-2.7.0/lib/python/ZODB/Transaction.py", line 232, in commit self._commit_begin(jars, subjars, subtransaction) File "/home/pw/Zope-2.7.0/lib/python/ZODB/Transaction.py", line 340, in _commit_begin jar.tpc_begin(self) File "/home/pw/Zope-2.7.0/lib/python/ZODB/Connection.py", line 692, in tpc_begin self._storage.tpc_begin(transaction) File "/home/pw/Zope-2.7.0/lib/python/ZODB/BaseStorage.py", line 142, in tpc_begin raise POSException.ReadOnlyError() ZODB.POSException.ReadOnlyError ----------------------------------------- So, am I just plain S.O.L.? Is this impossible? (Note: a similar message was sent earlier to dirstorage-users, but experimentation has shown me that the storage implementation doesn't seem to matter... i get the same result with filestorage, directorystorage, or clientstorage.) -- Paul Winkler http://www.slinkp.com

8 25

Announce: May Zope Bug Day!
by Chris Withers 25 May '04

25 May '04

Hi All, I'm pleased to announce the first a series of monthly bug days: What? Zope Bug Day working from http://collector.zope.org/Zope When? Friday 28th May - from when you wake up until when the day ends! Where? #zope-dev on irc.zope.org Come along and help if you've got a chance! Read this if you want to know how: http://dev.zope.org/CVS/BugDays cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

Explicit Acquisition within Acquistion.Implicit derived class
by Wyatt Anderson 25 May '04

25 May '04

Hello, I am encountering strange behavior when trying to dynamically set explicit Acquisition within an Acquisition.Implicit object. The strangeness seems to happen when I refresh the product only, but I do not feel certain of this which has me a little nervous. In a Python Product class, named TestAcquisition, I derive from Folder (which in turn gives me Acquistion.Implicit). This class defines an attribute which can dynamically be set to be acquired from nested TestAcquisition objects. In order to do this I test whether the attribute can be acquired (by checking to see if aq_parent has the attribute). In the top-level TestAcquisition object, this attribute should not be acquirable, and thus it will set it self.attribute = 1 In sub-objects of TestAcquisition, by default the attribute will be acquired (which I test and do in manage_afterAdd) by setting self.aq_explicit.attribute = Attribute.Acquired I can dynamically unset and set sub-objects acquisition of this attribute simply by setting self.attribute = 2 or self.aq_explicit.attribute = Attribute.Acquired within the TestAcquistion sub-object. This seems to be working as desired until I refresh the Product, even just simply adding a pdb.set_trace() as the only change. After the refresh all the subobjects that had explicitly been set to acquire the attribute all return the Special Acquisition Object (Acquisition.Acquired) instead of the desired value to be acquired. Is this a bug, something I just have to live with, or am I missing something on acquisition in my product? I'd really like to keep the implicit acquisition and not switch to Acquisition.Explicit. Thanks in advance! Wyatt

2 1

RE: Explicit Acquisition within Acquistion.Implicit derived class
by Wyatt Anderson 24 May '04

24 May '04

After further review, this strange behavior can happen simply after viewing the object a couple times. It seems erratic at best and obviously is not the behavior I'm after. What am I missing about explicit acquisition? From the Zope Developer's Guide: ------------- Sometimes, you want to dynamically make an implicitly acquiring object acquire explicitly. You can do this by getting the object's aq_explicit attribute. This attribute provides the object with an explicit wrapper that places the original implicit wrapper. ------------- Unfortunately, that's all that is said about aq_explicit. -----Original Message----- From: Wyatt Anderson [mailto:wyatt95@hotmail.com] Sent: Monday, May 24, 2004 1:01 PM To: 'zope-dev(a)zope.org' Subject: Explicit Acquisition within Acquistion.Implicit derived class Hello, I am encountering strange behavior when trying to dynamically set explicit Acquisition within an Acquisition.Implicit object. The strangeness seems to happen when I refresh the product only, but I do not feel certain of this which has me a little nervous. In a Python Product class, named TestAcquisition, I derive from Folder (which in turn gives me Acquistion.Implicit). This class defines an attribute which can dynamically be set to be acquired from nested TestAcquisition objects. In order to do this I test whether the attribute can be acquired (by checking to see if aq_parent has the attribute). In the top-level TestAcquisition object, this attribute should not be acquirable, and thus it will set it self.attribute = 1 In sub-objects of TestAcquisition, by default the attribute will be acquired (which I test and do in manage_afterAdd) by setting self.aq_explicit.attribute = Attribute.Acquired I can dynamically unset and set sub-objects acquisition of this attribute simply by setting self.attribute = 2 or self.aq_explicit.attribute = Attribute.Acquired within the TestAcquistion sub-object. This seems to be working as desired until I refresh the Product, even just simply adding a pdb.set_trace() as the only change. After the refresh all the subobjects that had explicitly been set to acquire the attribute all return the Special Acquisition Object (Acquisition.Acquired) instead of the desired value to be acquired. Is this a bug, something I just have to live with, or am I missing something on acquisition in my product? I'd really like to keep the implicit acquisition and not switch to Acquisition.Explicit. Thanks in advance! Wyatt

1 0

http://collector.zope.org/Zope/1347 - Zeo help
by Laurence 24 May '04

24 May '04

Hey guys, Sorry if this is a faq or otherwise covered elsewhere, but I've encountered quite a big problem with Zeo in my environment. I'm running FreeBSD 5.2.1 (Current as of last night) with Zope 2.7.0, Postgresql 7.4.2, Python 2.3.3 and psycopg-1.1.13. We have been developing with Zope using a single Zope server without Zeo and the time have come to migrate onto Zeo. Everything seemed to come accross smoothly (We brought up the new server in a single Data.fs config) and everything seemed fine so we moved onto setting up Zeo with the Data.fs. It seems that if we nest ZPT's more then three deep (ZPTA includes ZPTB which includes ZPTC) we get a seg fault and the Zope process dies (The Zeo server is fine). If we load ZPTB or comment out the inclusion of ZPTC everything works fine. It's when we encounter 3 or more layers that the server seg faults. I've included the output from gdb on the collector. I've been searching all day and hopefully someone can point me in the right direction. http://collector.zope.org/Zope/1347 Any ideas? Thanks, Laurence

3 2