[Zope3-dev] Re: Question regarding zc.relationship
Gary Poster wrote: On Jun 27, 2007, at 12:21 PM, Jürgen Kartnaller wrote: We store 100K relations this way. Cool. ZODB loads the referenced objects on demand. Very true. Additionally, I imagine Jürgen is using integer tokens, such as intids, to represent the objects within the index. yes Using that approach in particular, you should get the best results. The zc.relationship.intid.Container factory creates a container like this, for instance. Gary Jürgen Andreas Kopecky wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I got a question regarding the Relationship container part of zc.relationship: I realized that the Relationship class stores the objects which belong to the relation (source and target) as normal (strong?) python reference inside the Relationship object. My question: Is there and performance issue or data integrity issue to be expected when i store 10k or such relations with such behavior in the ZODB? I would have expected the Relationship class to use weak references to store the related objects. thanks in advance! - -regards Andreas Kopecky -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRoJjRWs7yVaOP/n9AQKWzwf+OGzG/A++z8DJcj68VFL+BOMDlV8ZGX/z 8N25P/pUB3Zvm6sK1oex/x9Cl1ofvQ1CwFob1CPjAyXfM2DcTvoymYtkD+p5nPdD JBl0TPawyhyhK2AV09X71Y8N3zKGoxQqg6yCHaJhAKvkWkwwOcxrUzHboDCKP6dz C/+hTtxEOSl/mK3pX0mulr/Frp/OKK728Q9IsrSt7D6x54/W6VFVia+vN7I+KdhW q/Hhi4jjBFKRbUpNC58fGrwPhKNFMCoq2sPJNi7g7vR0WxVvtkBoHX+6u3znOIc/ 4R8U7NNUyPkLkW7FzK5sXJxeUCmdTOVtNjP601FNVTENct1bYPV+rQ== =vtdZ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/gary%40zope.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: publisher performance
Roger Ineichen wrote: Hi Jürgen Betreff: [Zope3-dev] publisher performance [...] With this new version I also measured the time with zope as a trunk checkout (no eggs involved). The publisher is now twice as fast as it was before ! I'm writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core. newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher. What do you mean with and without eggs? Do you mean the flat dotted page name structure used in eggs? Does the egg package structure perform different in some way? Or do you mean something else? With without eggs I mean I used a trunk checkout for zope. With eggs I mean I use the eggified packages from zope. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] publisher performance
Here is a short story about the changes we made yesterday in the zope.security package : Yesterday we deployed our first portal using buildout and eggs :) :) Before we could do this we run into performance problems :( :( On our development test instance we found that we got a 5% CPU load for each of our remotetask threads. Because we have 5 of them running per portal and we have 3 portals active... :( After some investigation with the profiler : lovely.remotetask throws an IndexError exception if there is no job to do. It is doing this once a second. The publisher gets a traceback for the exception using python's traceback module. traceback.extract_stack() uses python's linecache module. Now here is the problem coming in : linecache is extremely slow when using eggs ! We could measure 54 ms for the time spent in the publisher ! So we changed remotetask to not throw an IndexError. But the publisher still took 27ms. Profiling again showed us that traceback.extract_stack() was still called somewhere. Finally we found it in zope.security.manager.py newInteraction was storing a traceback to be able to print a nice traceback in case newInteraction is called a second time. This is really a good thing for the developer because you get a very detailed error report which shows you exactly from where newInteraction was called the first time. But for which price: Removing the extraction of the traceback put down the publisher time to ! 2ms ! So we decided to remove this feature. The change is now in the newest egg for zope.security version 3.4.0b2 With this new version I also measured the time with zope as a trunk checkout (no eggs involved). The publisher is now twice as fast as it was before ! I'm writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core. newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher. Regards Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Bare excepts in z3c.zalchemy
Chris Withers wrote: Jürgen Kartnaller wrote: The fact that you get an error there is an indication that something in your tests still has a file open in some way, you should fix that ;-) The something was/is sqlite ! I don't know what that's supposed to mean, since I have little context on the tests, but if a test has managed to get sqlite to open a file, then it should make sure that file gets closed again, surely? Of course you are right. It just means that I had no idea how I could solve the problem. Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Bare excepts in z3c.zalchemy
Philipp von Weitershausen wrote: For the lack of a better mailinglist, I'm posting this to zope3-dev: z3c.zalchemy is pretty cool, but the tons of bare except clauses make me a bit uneasy. When I see them, I wonder what this code is expecting to fail and why. Plus, there are no comments as to why a try/except was used in the first place. I would offer my help if I knew enough about SQLAlchemy and what kind of things can go wrong in those cases. Either way, I'd feel better using and recommending zalchemy if it didn't have those bare except clauses... Hi Philip. datamanager.py: 2 try/except They are there because it is possible that a table already exists when trying to create it or doesn't exist when trying to delete it. As I remember when I wrote this I couldn't find a better way, but I'm there is a better way in the latest version of sqlalchemy. container.py: 2 try/except get speaks for itself, it think! __len__ contains it to be able to view the container even if there is no database connection. Otherwise if the database connection is lost you even can not view the container in zmi. So tons == 4 :) Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Bare excepts in z3c.zalchemy
Philipp von Weitershausen wrote: Jürgen Kartnaller wrote: datamanager.py: 2 try/except They are there because it is possible that a table already exists when trying to create it or doesn't exist when trying to delete it. As I remember when I wrote this I couldn't find a better way, but I'm there is a better way in the latest version of sqlalchemy. Good to know. container.py: 2 try/except get speaks for itself, it think! Yes, those aren't bare excepts. Those make sense to me :) __len__ contains it to be able to view the container even if there is no database connection. Otherwise if the database connection is lost you even can not view the container in zmi. So tons == 4 :) Okay, okay, I was exaggerating :). But there are some bare excepts in the tests as well: $ grep -nH -rI except: * datamanager.py:153:except: datamanager.py:162:except: Maybe one can figure out which exception we need to catch here. testing/__init__.py:31:except: tests/test_zalchemy.py:35:except: tests/test_zalchemy.py:39:except: tests/test_zalchemy.py:43:except: Yes these stupid except's are because of windows :( I wrote the first version on windows and had the problem that windows didn't let me delete the files. Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Bare excepts in z3c.zalchemy
Chris Withers wrote: Jürgen Kartnaller wrote: Yes these stupid except's are because of windows :( I wrote the first version on windows and had the problem that windows didn't let me delete the files. It is possible to do this right, I've had to in the past... The fact that you get an error there is an indication that something in your tests still has a file open in some way, you should fix that ;-) The something was/is sqlite ! Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Bug in zc.catalog.index
Gary Poster wrote: On Feb 21, 2007, at 8:10 PM, Roger Ineichen wrote: Hi alga Is this mine or is there something wrong with zc.catalog.index, BTreeAPI or? - self._add_value(doc_id, value) File D:\reflineRecruiter\app\trunk\src\zc\catalog\index.py, line 115, in _add_value values_to_documents[added] = self.BTreeAPI.TreeSet((doc_id,)) AttributeError: 'module' object has no attribute 'TreeSet' - Any hints? Hi Roger. zc.catalog 1.1 is stable, 1.2 is dev. The trunk of zc.catalog, and the upcoming 1.2 release line, works with the ZODB trunk (ZODB 3.8, Zope 3.4), which is gaining some tools to manage the two new families there, the 64 bit ints (L) and the 32 bit ints (I). The 1.1 release line should work with both ZODB 3.7/Zope 3.3 and ZODB 3.8/Zope 3.4. It sounds like that's what you want. Currently pypi only has the stable 1.1 branch (http://www.python.org/pypi/zc.catalog). There's also a 1.1 tag in svn. I'll make a 1.1 branch from that tag if there are any bug fixes that need to go there (or you are welcome to if that helps your development or release management). The current trunk of zc.catalog contains a change which is not backward compatible to existing catalogs and there is also no migration script ! Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martijn Faassen wrote: Martin Aspeli wrote: Martijn Faassen wrote: Hi there, We had a Grok sprint in Germany over the weekend, and we got two reports about it: Rock on :) What is the current state of the art in terms of Grok examples and documentation? What is the best place to look to find out about the latest development techniques and possiiblities? Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn That looks really promising, looking forward to get more impressions from Phillip at the snowsprint. Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: expected string or Unicode object
How should ZODB know how to serialize your xmpp.Client and /or xmpp.protocol.JID ? If connectOnStartup is True your code creates these objects. Jürgen Florian Lindner wrote: Hello, everytime I add my utility I get: 2006-12-04T22:44:26 ERROR SiteError http://horus.local:8080/++etc++site/default/+/AddJabberClient.html%3D Traceback (most recent call last): File /home/florian/Zope3/src/zope/publisher/publish.py, line 138, in publish publication.afterCall(request, obj) File /home/florian/Zope3/src/zope/app/publication/browser.py, line 78, in afterCall super(BrowserPublication, self).afterCall(request, ob) File /home/florian/Zope3/src/zope/app/publication/zopepublication.py, line 167, in afterCall txn.commit() File /home/florian/Zope3/src/transaction/_transaction.py, line 395, in commit self._commitResources() File /home/florian/Zope3/src/transaction/_transaction.py, line 495, in _commitResources rm.commit(self) File /home/florian/Zope3/src/ZODB/Connection.py, line 498, in commit self._commit(transaction) File /home/florian/Zope3/src/ZODB/Connection.py, line 543, in _commit self._store_objects(ObjectWriter(obj), transaction) File /home/florian/Zope3/src/ZODB/Connection.py, line 570, in _store_objects p = writer.serialize(obj) # This calls __getstate__ of obj File /home/florian/Zope3/src/ZODB/serialize.py, line 407, in serialize return self._dump(meta, obj.__getstate__()) File /home/florian/Zope3/src/ZODB/serialize.py, line 416, in _dump self._p.dump(state) TypeError: expected string or Unicode object, NoneType found 127.0.0.1 - - [4/Dec/2006:22:44:26 +0200] POST /++etc++site/default/+/AddJabberClient.html%3D HTTP/1.1 500 89 http://horus.local:8080/++etc++site/default/+/AddJabberClient.html=; Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko) I have already tried on zope3-users but got no solution. This is my code: interfaces.py: from zope.interface import Interface from zope.schema import TextLine, Password, Bool class IJabberClient(Interface): JID = TextLine( title = uJabber ID, description = uJabber ID ([EMAIL PROTECTED]). You need to reconnect in order to take effect., required = True ) password = Password( title = uPassword, description = uPassword for the jabber account, required = True ) connectOnStartup = Bool( title = uConnect on startup, description = uAutomatically connect when Zope starts and also when the object is newly added (what you are about to do)., default = True) jabberclient.py: from interfaces import IJabberClient from zope.interface import implements from persistent import Persistent from zope.app.container.contained import Contained import xmpp class JabberClient(Persistent, Contained): implements(IJabberClient) JID = u password = u connectOnStartup = True status = uoffline def finishInitialization(self): Finish the rest of the initialziation that can't be done in __init__. if self.connectOnStartup: self.setStatus(available) else: self.setStatus(offline) def setStatus(self, newStatus): if self.status == offline and newStatus == available: self.jabberID = xmpp.protocol.JID(self.JID) self.client = xmpp.Client(self.jabberID.getDomain(), debug=[]) self.client.connect() self.client.auth(self.jabberID.getNode(), self.password) self.client.sendPresence(self.jabberID) if self.status == available and newStatus == offline: # disconnect pass self.status = newStatus def getStatus(self): return self.status def onObjectAdded(event): if IJabberClient.providedBy(event.object): event.object.finishInitialization() configure.zcml configure xmlns=http://namespaces.zope.org/zope; xmlns:browser=http://namespaces.zope.org/browser; class class=.jabberclient.JabberClient require permission=zope.ManageServices interface=.interfaces.IJabberClient set_schema=.interfaces.IJabberClient / /class browser:addform schema=.interfaces.IJabberClient label=Add a JabberClient object content_factory=.jabberclient.JabberClient name=AddJabberClient.html permission=zope.ManageServices set_before_add=JID password connectOnStartup / browser:addMenuItem title=Jabber Client class=.jabberclient.JabberClient permission=zope.ManageServices view=AddJabberClient.html / browser:editform schema=.interfaces.IJabberClient
[Zope3-dev] Re: strange behavior of intid-utility
Hi Tom. The NotYet exception tells you, that the object you (or in this case the IntId utility) want to get a key refence for is not Not Yet connected to a database. Your specific case is reported here : http://zope.org/Collectors/Zope3-dev/463 Jürgen Tom Gross wrote: Here is the traceback: Error in test test_withoutintids (myproduct.ftests.test_wf.WorkflowTestCase) Traceback (most recent call last): File /usr/lib/python2.4/unittest.py, line 260, in run testMethod() File /mnt/zope/ldev/var/zope/lib/python/myproduct/ftests.py, line 20, in test_withoutintids basic='mgr:mgrpw') File /mnt/zope/ldev/app/zope3/lib/python/zope/app/testing/functional.py, line 357, in publish publish(request, handle_errors=handle_errors) File /mnt/zope/ldev/app/zope3/lib/python/zope/publisher/publish.py, line 133, in publish result = publication.callObject(request, obj) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/publication/zopepublication.py, line 161, in callObject return mapply(ob, request.getPositionalArguments(), request) File /mnt/zope/ldev/app/zope3/lib/python/zope/publisher/publish.py, line 108, in mapply return debug_call(obj, args) File /mnt/zope/ldev/app/zope3/lib/python/zope/publisher/publish.py, line 114, in debug_call return obj(*args) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/container/browser/adding.py, line 142, in action content = factory() File /mnt/zope/ldev/app/zope3/lib/python/zope/component/factory.py, line 37, in __call__ return self._callable(*args, **kw) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/workflow/stateful/definition.py, line 115, in __init__ self.__states[self.getInitialStateName()] = initial File /mnt/zope/ldev/app/zope3/lib/python/zope/app/workflow/definition.py, line 87, in __setitem__ setitem(self, self.__data.__setitem__, name, object) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/container/contained.py, line 593, in setitem notify(event) File /mnt/zope/ldev/app/zope3/lib/python/zope/event/__init__.py, line 23, in notify subscriber(event) File /mnt/zope/ldev/app/zope3/lib/python/zope/component/event.py, line 26, in dispatch for ignored in zope.component.subscribers(event, None): File /mnt/zope/ldev/app/zope3/lib/python/zope/component/_api.py, line 130, in subscribers return sitemanager.subscribers(objects, interface) File /mnt/zope/ldev/app/zope3/lib/python/zope/component/registry.py, line 290, in subscribers return self.adapters.subscribers(objects, provided) File /mnt/zope/ldev/app/zope3/lib/python/zope/interface/adapter.py, line 535, in subscribers subscription(*objects) File /mnt/zope/ldev/app/zope3/lib/python/zope/component/event.py, line 33, in objectEventNotify adapters = zope.component.subscribers((event.object, event), None) File /mnt/zope/ldev/app/zope3/lib/python/zope/component/_api.py, line 130, in subscribers return sitemanager.subscribers(objects, interface) File /mnt/zope/ldev/app/zope3/lib/python/zope/component/registry.py, line 290, in subscribers return self.adapters.subscribers(objects, provided) File /mnt/zope/ldev/app/zope3/lib/python/zope/interface/adapter.py, line 535, in subscribers subscription(*objects) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/intid/__init__.py, line 163, in addIntIdSubscriber key = IKeyReference(ob, None) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/component/hooks.py, line 96, in adapter_hook return siteinfo.adapter_hook(interface, object, name, default) File /mnt/zope/ldev/app/zope3/lib/python/zope/security/adapter.py, line 88, in __call__ adapter = self.factory(*args) File /mnt/zope/ldev/app/zope3/lib/python/zope/app/keyreference/persistent.py, line 41, in __init__ raise zope.app.keyreference.interfaces.NotYet(object) NotYet: zope.app.workflow.stateful.definition.State object at 0xb47b786c Philipp von Weitershausen wrote: Tom Gross wrote: I have a site with some utilities. One is a zope.app.intid.UniqueIdUtility, which seems to be the cause of the problem (see the test). A NotYet-Exception is raised, when I try to add a zope.app.workflow.StatefulProcessDefinition-object to the container with the utilities. I can add a StatefulProcessDefinition-object to an empty container. I'm using Zope 3.3 and Python 2.4.3. Got a traceback handy? (Remember: any error description should *always be acocmpanied by a traceback, otherwise it's not very useful) I have a suspicion as to what this is about (something's missing a __parent__ attribute), but I'd like to see the traceback first for confirmation. Yes, I could execute the test somehow, but that would take me a couple of minutes on my slow machine, and you already know what the error is, so you can just as well describe it to me in detail :). Note that providing a test is highly appreciated as it helps with the reproduceability of the problem...
[Zope3-dev] Re: layers can't be new style classes?
Hi Chris. Look at z3c.sampledata.layer, I provide a testlayer there. Maybe you need to provide the __bases__! Jürgen Chris Withers wrote: Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? cheers, Chris ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/dublincore/ Dublin Core property to use Dublin Core meta data as simple properties.
Fred Drake wrote: On 8/14/06, Jürgen Kartnaller [EMAIL PROTECTED] wrote: It definitely doesn't obsolete the existing implementation. DCProperty is the other way around. DCProperty allows access to DC meta data via simple properties. I agree that these should co-exist. I'm not sure just what motivated DCProperty, but it's clearly different from the partial adapter. The motivation for theh partial adapter was that for some content, some of the data fields correspond directly to DC elements. For those, we wanted the DC adapter to use the fields instead of storing the information outside the object. When defining our content types we almost always end up with properties which are already defined in Dublin Core. Also the Dublin Core implementation of Zope 3 gives us a lot of meta data for free. Dublin Core has the advantage that the access to common information is standardized but it is not as easy to access DC meta data as it is to access a simple property of the content type. So we decided to have the advantage of Dublin Core and the advantage of simple property access in one. Regards Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/dublincore/ Dublin Core property to use Dublin Core meta data as simple properties.
Florian Lindner wrote: Am Montag, 14. August 2006 12:52 schrieb Jürgen Kartnaller: Log message for revision 69463: Dublin Core property to use Dublin Core meta data as simple properties. Changed: A Zope3/trunk/src/zope/dublincore/property.py A Zope3/trunk/src/zope/dublincore/property.txt A Zope3/trunk/src/zope/dublincore/tests/test_property.py Do I understand this change correctly that it obsoletes zope.dublincore.annotatableadapter.partialAnnotatableAdapterFactory? It definitely doesn't obsolete the existing implementation. DCProperty is the other way around. DCProperty allows access to DC meta data via simple properties. partialAnnotatableAdapterFactory allows access via DC meta data to content properties. Quote from zope/dublincore/tests/partial.txt which describes the partialAnnotatableAdapterFactory: Sometimes we want to include data in content objects which mirrors one or more Dublin Core fields. In these cases, we want the Dublin Core structures to use the data in the content object rather than keeping a separate value in the annotations typically used. What fields we want to do this with can vary, however, and we may not want the Dublin Core APIs to constrain our choices of field names for our content objects. Should the partialAnnotatableAdapterFactory therefore be removed/deprecated? No Regards Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] traceback when running tests for zope.app.component
Trying to run python test.py --package=zope.app.component results in : Running unit tests: Ran 318 tests with 0 failures and 0 errors in 6.118 seconds. Running zope.app.testing.functional.Functional tests: Set up zope.app.testing.functional.Functional Traceback (most recent call last): File test.py, line 61, in ? result = testrunner.run(defaults) File /home/juka/zope/testtrunk/src/zope/testing/testrunner.py, line 240, in run failed = run_with_options(options) File /home/juka/zope/testtrunk/src/zope/testing/testrunner.py, line 390, in run_with_options setup_layers, failures, errors) [snip] /home/juka/zope/testtrunk/src/zope/app/publisher/browser/metaconfigure.py, line 26, in ? from zope.app import zapi, layers, skins zope.configuration.xmlconfig.ZopeXMLConfigurationError: File /home/juka/zope/testtrunk/zopeskel/etc/ftesting.zcml, line 13.2-13.32 ZopeXMLConfigurationError: File /home/juka/zope/testtrunk/src/zope/app/configure.zcml, line 8.2-8.30 ZopeXMLConfigurationError: File /home/juka/zope/testtrunk/src/zope/app/meta.zcml, line 8.0-8.57 ZopeXMLConfigurationError: File /home/juka/zope/testtrunk/src/zope/app/publisher/meta.zcml, line 5.2-5.49 ZopeXMLConfigurationError: File /home/juka/zope/testtrunk/src/zope/app/publisher/browser/meta.zcml, line 90.4-94.10 ImportError: cannot import name layers Running python test.py --package=zope.app or python test.py works fine. Jürgen -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: traceback when running tests for zope.app.component
Benji York wrote: I emailed the committer Friday about this, but no fix has been forthcoming, so I reverted the offending revisions. Hopefully a revised version can be reapplied soon. Still the same problem after your revert ! Jürgen -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: rdb: Disappearing Connection
Dieter Maurer wrote: Jim Washington wrote at 2005-12-13 21:40 -0500: ... Now, looking closer at the code, a ping like this might be not too bad, because isConnected() is only called when a connection is requested, not for every SQL statement executed. So, it might not be so onerous as originally thought. Still not ideal, though. Be careful what you do when you find that isConnected() returns false. Note, that, in general, it would be a bug to just reopen a new connection in this case: previous operations against the connection might have been lost without notice when you simply reopen a new connection and do as if nothing bad had happened. Instead, you should reopen the connection and then raise an exception similar to ZODB.POSException.ConflictError. Hopefully, the publisher will handle this kind of exception correctly (by retrying the complete request). MySQL::Ping will automatically reopen a closed connection in a way where the existing connection object can still be used. If MySQL::Ping fails something really bad is going on. To reduce the number of ping's in my application I used a timer which was tested before every call to a database function. If the timer expired I did a ping to ensure mysql is reconnected. This is the code sqlobject is using : while (1): try: return cursor.execute(query) except MySQLdb.OperationalError, e: if e.args[0] == 2013: # SERVER_LOST error if self.debug: self.printDebug(conn, str(e), 'ERROR') else: raise So, checking for SERVER_LOST and then eventually using MySQL::Ping would do the trick. Jürgen -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Return of empty page
Jim Fulton wrote: On Tue, 2005-11-15 at 20:42 +0100, jürgen Kartnaller wrote: When I do this in my page template with an unknown provider name : tal:block replace=structure provider:unknown / then I receive an empty page in my browser. There is no error message and no traceback. The same happens when I try to access a non existing skin with ++skin++someSkinName . I'm running Zope from the trunk with the default settings in zope.conf . Look in the error log (errors link off of the zmi). There is also no message in the log file. I've noticed lately that many errors in ZPT are causing empty pages. I think this might be recent. I wonder if someone broke something in zpt lately. It would be great if someone could try to figure out if we have some general zpt error-handling problem, as I suspect we do. Jim -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Return of empty page
When I do this in my page template with an unknown provider name : tal:block replace=structure provider:unknown / then I receive an empty page in my browser. There is no error message and no traceback. The same happens when I try to access a non existing skin with ++skin++someSkinName . I'm running Zope from the trunk with the default settings in zope.conf . Jürgen -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deleting utilities in site management doesn't work correct
Hi Tres. I could now manage to have a relatively simple test (see attached file). 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 Jürgen Tres Seaver wrote: Stephan Richter wrote: On Wednesday 05 October 2005 17:00, jürgen Kartnaller wrote: When more than one utility is selected for deleting in the site management view, only the first selected utility is deleted. The problem is that the content of regManager is changed inside the while iteratating over it. Here is the fix which works for me : If this is applicable, can please someone check it into the trunk ? The file is in zope.app.component.browser Could you create an issue in the bug collector for this? If you cannot create a unit test for it, then I will. :-) Stephan, I was in the midst of writing a 'tools.txt' doctest which would have provided the basis for such a test when I wrote my keening post. In case you missed the attacment, here it is again. Tres. -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -- --- Jürgen Kartnaller mailto:juergen_at_kartnaller.at http://www.kartnaller.at http://www.mcb-bregenz.at --- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deleting utilities in site management doesn't work correct
Stephan Richter wrote: On Wednesday 05 October 2005 17:00, jürgen Kartnaller wrote: When more than one utility is selected for deleting in the site management view, only the first selected utility is deleted. The problem is that the content of regManager is changed inside the while iteratating over it. Here is the fix which works for me : If this is applicable, can please someone check it into the trunk ? The file is in zope.app.component.browser Could you create an issue in the bug collector for this? If you cannot create a unit test for it, then I will. :-) Hi Stephan. It's in the collector now, so you can start creating the unit test :) I'm looking forward to see this code because I'm completely stuck on this. The problem to build such kind of tests is to setup a test environment which contains enough context for the test case. And this really takes a lot of time for a none zope guru. Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Keening for the poultry
Hi Tres.
I just want to show you what I have so far.
See the attached test file.
I took me really a lot of time to figure out all these things.
Currently I'm at a point where the view is missing the activeTool which
is set up in __init__.
How should a zope rookie be able to write such a test if the zope pro
gives up :)
Jürgen
Tres Seaver wrote:
I have been trying to write a doctest for the tools stuff to show
Jürgen Kartnaller how[1], so he could write a test for the bug he found
in tool deletion[2].
While writing the test, I found myself mourning for the huge flock of
assorted fowl I was slaughtering, trying to get the planets aligned[3]
so that the SiteManagerView could actually install a tool implmentation.
Hugh, this sentence really needs a dictionary for a non native english
speaker :)
I have finally given up, and ask abjectly for elightenment from the
hierarchs of Z3. Please see the attached doctest and setup code for my
efforts so far,
[1] http://article.gmane.org/gmane.comp.web.zope.zope3/14477
[2] http://article.gmane.org/gmane.comp.web.zope.zope3/14459
[3] No, I'm not mixing metaphors: the ritual slaughter is precisely
intended to cause the planets to realign themselves.
Removing-bloody-apron-and-picking-down-out-of-my-ears'ly,
Tres.
--
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
==
The Tools View
==
from zope.app import zapi
from zope.app.component.browser.tools import SiteManagementView
from zope import interface
class IFooUtil(interface.Interface):
... pass
class FooUtil(object):
... interface.implements(IFooUtil)
from zope.component.interfaces import IFactory
from zope.component.factory import Factory
from zope import component
from zope.app.security import protectclass
protectclass.protectName(Factory, '__call__', 'zope.public')
factory = Factory(FooUtil,
... 'Utility for foo',
... 'This factory creates a foo utility.')
component.provideUtility(factory, IFactory, 'IFooUtil')
from zope.publisher.browser import TestRequest
request = TestRequest()
view = SiteManagementView('context', request)
view.getTools()
[]
view.update()
u''
request.form['ADD-TOOL-SUBMIT']='submit'
request.form['type_name']='IFooUtil'
request.form['id']='foo1'
view.update()
component.getUtility(IFooUtil, 'foo1') is not None
True
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deleting utilities in site management doesn't work correct
Thanks Tres,
I'll give it a try.
Jürgen
Tres Seaver wrote:
jürgen Kartnaller wrote:
Hi Tres,
I would really like to make a test for this but I have no idea how to start.
It took me 10 minutes to fix the problem but I think it will take me 10
hours to write the test.
If you can point me to a starting direction or just give me an example
test somewhere I will give it a try !
Hmmm, the code in src/zope/app/component/browser has no tests at all.
There is a 'xxx_tests' directory, which looks to have a bunch of
now-invalid tests, moved aside by Stephan during servicegeddon. I'll CC
him just in case some of those tests were supposed to come back online.
For your bug, I would start by writing a doctest for the tools.py
module, something like:
1. Create a 'tests' subdirectory in the 'browser' directory, and
give it an empty '__init__.py'::
$ mkdir src/zope/app/component/browser/tests
$ cat src/zope/app/component/browser/tests/__init__.py
# Python package
^D
2. Add a 'tests/test_tools.py' module, with boilerplate to run
the doctests in 'tools.txt':
$ cat src/zope/app/component/browser/tests/test_tools.py
import unittest
from zope.testing import doctest
from zope.app.testing.placelesssetup import setUp
from zope.app.testing.placelesssetup import tearDown
def test_suite():
return unittest.TestSuite((
doctest.DocFileSuite('../tools.txt',
setUp=setUp,
tearDown=tearDown),
))
if __name__ == __main__:
unittest.main(defaultTest='test_suite')
^D
3. Start writing 'tools.txt', documenting the behavior of the
methods of the SiteManagementView class. You could write only
a test for 'delete' first, which should fail until you apply
your patch. Look at 'src/zope/app/component/adapterregistry.txt'
for an example doctest file.
$ vim src/zope/app/component/browser/tools.txt
4. Run the tests, iteratively, during development:
$ python test.py -u zope.app.component.browser
5. Check in the new tools.txt and tests/ directory:
$ svn add src/zope/app/component/browser/tools.txt
$ svn add src/zope/app/component/browser/tests
$ svn commit -m Ensure that SiteManagerView.delete doesn't\
bite it's own tail.
Hope that helps,
Tres.
--
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deleting utilities in site management doesn't work correct
Hi Tres, I would really like to make a test for this but I have no idea how to start. It took me 10 minutes to fix the problem but I think it will take me 10 hours to write the test. If you can point me to a starting direction or just give me an example test somewhere I will give it a try ! Jürgen Tres Seaver wrote: jürgen Kartnaller wrote: When more than one utility is selected for deleting in the site management view, only the first selected utility is deleted. The problem is that the content of regManager is changed inside the while iteratating over it. Here is the fix which works for me : If this is applicable, can please someone check it into the trunk ? The file is in zope.app.component.browser --- Index: tools.py === --- tools.py (revision 38746) +++ tools.py (working copy) @@ -192,7 +192,8 @@ tool = self.activeTool regManager = self.context[tool.folder].registrationManager names = self.request.form['selected'] -for reg in regManager.values(): +values=[v for v in regManager.values()] +for reg in values: if reg.provided.isOrExtends(tool.interface) and reg.name in names: component = reg.component reg.status = interfaces.registration.InactiveStatus --- Jürgen +1 for this fix, which should be applied to the 3.1 and 3.0 branches, as well (assuming that they have the bug). A unit test which verified that multiple deletions actually worked would be ideal, of course. Tres. -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Deleting utilities in site management doesn't work correct
When more than one utility is selected for deleting in the site management view, only the first selected utility is deleted. The problem is that the content of regManager is changed inside the while iteratating over it. Here is the fix which works for me : If this is applicable, can please someone check it into the trunk ? The file is in zope.app.component.browser --- Index: tools.py === --- tools.py(revision 38746) +++ tools.py(working copy) @@ -192,7 +192,8 @@ tool = self.activeTool regManager = self.context[tool.folder].registrationManager names = self.request.form['selected'] -for reg in regManager.values(): +values=[v for v in regManager.values()] +for reg in values: if reg.provided.isOrExtends(tool.interface) and reg.name in names: component = reg.component reg.status = interfaces.registration.InactiveStatus --- Jürgen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Issue 363
Is there really nobody willing to do this change or at least comment it ?
Am I completely wrong with this fix ?
Jürgen
jürgen Kartnaller wrote:
I did a check for issue 363 :
A GetoptError exception occures because of the uppercase L in the option
list.
zope ftp only accepts lower case options l,a and d.
As I can see the implemented LIST command only uses -d option.
Am I right ?
For now this issue can be fixed like this in zope/server/ftp/server.py :
--- server.py (revision 29853)
+++ server.py (working copy)
@@ -206,7 +206,7 @@
opts = ()
if args.strip().startswith('-'):
try:
-opts, args = getopt(args.split(), 'lad')
+opts, args = getopt(args.split(), 'Llad')
except GetoptError:
self.reply('ERR_ARGS')
return
Someone with checkin rights can please do the cahnge.
Jürgen
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
