Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
On Tue, 23 Jun 2009 16:15:12 +0200, Fabio Tranchitella wrote: Hello all! In the last couple of weeks Brian Sutherland, Matthias Klose and I worked together to improve the Zope packaging for Debian and Ubuntu. This e-mail summarizes the problems we faced, the decisions that have been taken and the changes that we will upload to experimental and unstable in the next weeks. Short summary = We switch from a monolithic Zope 3 package to individual packages for the libraries that are part of the ZTK (Zope Toolkit). Zope instance management tools are not supported anymore, as we suggest the use of WSGI. We also drop support for Zope 2 and Plone in Debian and Ubuntu, asking for the removal of the packages from the distribution. I am certainly one person that did use the Debian packages at the time when people first started to suggest against it. I dropped this habit when I needed to work most of the time with custom Zope and Plone versions that were too new or too rare to be in Debian yet. But I'm still using Debian's python2.4 right now to bootstrap my buildouts. The main problem for Zope2 is that the current stable upstream branch (2.12) still requires pthon2.4. This is not acceptable in Debian and Ubuntu, and Zope 2 is right now the only stopper for the removal of python2.4 from both Debian and Ubuntu. What's the reason for the removal of python2.4? Is there a technological reason, or is this a policy decision? Don't forget that Plone users, who are also the biggest consumer group of Zope / ZTK, still will be users of 2.4 for a while. The unified installer is not the only installation method used for Plone, in fact many users and the majority of deployments use python + buildout. These users will need to read documentation and do installation to be able to bootstrap their buildout, which is not exactly a reason for them to choose Debian / Ubuntu in this case. -- Balazs Ree ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hg mirror available
On Thu, 18 Jun 2009 14:28:13 -0300, Sidnei da Silva wrote: Hi Wolfgang, On Thu, Jun 18, 2009 at 7:31 AM, Wolfgang Schnerringw...@gocept.com wrote: * Sebastien Douche sdou...@gmail.com [2009-06-18 01:34]: This is a first attempt to build an Mercurial mirror : http://hg.zope.mirrors.securactive.org/ How did you convert the repository? I'm asking because I noticed that basically all SVN-DVCS conversion tools (hg convert, git-svn, bzr svn-import, svn2bzr, svn-fast-export.py, svn-all-fast-export.cpp) do not convert the history properly, more precisely, history that happened on branches is lost: 1. import /trunk/foo.txt 2. branch /trunk to /branches/mybranch 3. edit /mybranch/foo.txt 4. merge /mybranch to /trunk If you now ask svn for the history of /trunk/foo.txt (say with 'svn log'), you see both steps 3 and 4. After conversion to a DVCS with one of the above mentioned tools, you only see step 4, while step 3 never happened in the DVCS repository. I think that's unacceptable, most importantly because all commit messages that happened on branches are lost that way. Does somebody here know something about this phenomenon, by any chance? Am I missing something? Here's some context about this from one of the Bazaar developers, John Arbash Meinel. Hopefully that will solve some of your questions? In pretty much all dvcs merging a content exactly back to trunk does not generate a change message when doing bzr log foo.txt. I'm not really sure what he means by edit and then merge without a commit inbetween. So I'm assuming there is one. Now, what really matters is whether or not *Subversion* recorded 4 correctly, such that it can actually see that it was a merge from 3. My understanding is that before svn 1.5 that isn't possible. So you are left with trying to infer that sort of thing from the history. Which would be possible, but probably expensive. I'm pretty sure SVN represents (4) as not a *merge* but as an indentical commit. I don't have a great answer there. Though the fact that Wolfgang says svn shows both... I suppose because svn log shows everything across all branches? I'm somewhat confused here. According to my understanding: - all DVCS shows, if a merge is done, the changesets that origin from the merged branch. (this is the normal operation) - afaik svn does _not_ show this, what's more, it does not store any metadata about the merges or changesets involved. When doing the merge you really select a diff of the branch by specifying which changesets you want to include back in trunk. This is why it's so important with svn to note in the commit message, which revisions from which branch you merged. Otherwise you would not know at all what has been merged. So although, DVCS could represent the information about the merged changesets, this information will not be imported from SVN, simply, because the information is not represented in SVN. I'd like to add that I'm not using Hg, I am only using bazaar and svn, and I'm talking from what I experienced in practice with working on various svn repos and bzr. It's possible that newer svn does try to attack this problem by storing more metadata with the merges, which then would make sense to be considered at a DVCS import, but I believe that in the vast majority of svn repositories that you would consider importing, this information would not be there anyway, due to the fact that they are product of the older svn version. -- Balazs Ree ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.buildout broken
On Fri, 24 Apr 2009 13:10:30 +0200, Marius Gedminas wrote: On Fri, Apr 24, 2009 at 05:56:45AM +0200, Roger Ineichen wrote: Hi everybody Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? It is always interesting to see the failures, but attaching large log files to emails is not very polite. True for large files, but a traceback is not that large _imo_. Depends on your connection of course. Also, we are on a development list, so if somewhere, then here tracebacks are on topic. Solution: use a pastebin. I disagree: pastebin is good for linking from irc, but when I come back to the archive I would like to see the details even when the pastebin entry is gone. -- Balazs Ree ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [zope.testing.doctest] a nasty surprise
On Thu, 10 Apr 2008 11:50:35 -0400, Benji York wrote: Dieter Maurer wrote: As the community (apparently) strongly favors doctest over unittest, I wrote my first test based on zope.testing.doctest. And promptly, I was badly surprised In order to analyse a difficult problem, I added from dm.pdb import zpdb; zpdb.set_trace() in the doctest (dm.pdb.zpdb is my Zope aware PDB extension) The standard PDB works fine. I'm sure you're extended version can be tweaked to as well. I have similar issues with ipdb. - similar in sense that I cannot use it when running from doctests. ipdb is a lightweight component that enables entering ipython when import ipdb; ipdb.set_trace() is called. Those of you that use ipython and also develop with doctests a lot, will understand why it would be a nice to have also from doctests. In case of ipdb I had no parameters problem like Dieter encountered with zpdb, however I observed that the doctest runner needs to redirect input and output while running tests, which are specifically routed back to stdin and stdout while pdb.set_trace is entered, to enable interactivity. This is done by monkeypatching pdb if I remember well. But the same does not happen with ipdb, of course. So, my conclusion is that while doctests work well with the standard pdb, any alternate debugger must be supported explicitely (by changing the doctest code). As with ipdb, this may be the case with zpdb as well. Best wishes -- Balazs Ree ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: running unit tests for Zope 2.8
Hi Geoff, On Mon, 13 Mar 2006 18:04:14 -0500, Geoff Davis wrote: bin/zopectl test --dir=/opt/Zope-2.8/lib/python/Products/SiteAccess/tests/ which yields the following: Running tests via: /usr/local/bin/python /opt/Zope-2.8/bin/test.py -v --config-file /home/zope/zopefix/etc/zope.conf --libdir Products --dir=/opt/Zope-2.8/lib/python/Products/SiteAccess/tests/ Running unit tests at level 1 Running unit tests from /opt/Zope-2.8/lib/python/Products/SiteAccess/tests Parsing /home/zope/zopefix/etc/zope.conf -- Ran 0 tests in 0.000s In my experience the --libdir must point to the *product* root and never to the test dir itself. It seems that the runner iterates through the test, ftest dirs under this root and in your case it finds none (since you are already inside it). So I would use bin/zopectl test --libdir=/opt/Zope-2.8/lib/python/Products/SiteAccess If I would want to run test from a specific file only, I would add the filename filter to the end like bin/zopectl test --libdir=/opt/Zope-2.8/lib/python/Products/SiteAccess \ Products/SiteAccess/tests/test_one.py and so on... -- Balazs Ree jabber + email: [EMAIL PROTECTED] ICQ: 75955071 AIM + skype: reebalazs ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] [ANN] jsonserver for Z2 version 1.1.pre3 released [AJAX]
News in version 1.1.pre3 - bug fixes - more advanced Five support - base demos (quickstart) re-made with Five, besides the old five-less demos are available as well. - more advanced demos: the Click-to-edit-title example and a drag-and-drop shopping cart mini application. All done with plain Zope. General information --- Jsonserver provides an alternative way of AJAX client-server communication on Zope. Jsonserver enables Zope to act as a JSON-RPC server. JSON-RPC is an XML-RPC replacement. It is built on JSON, a javascript based data interchange format. JSON has bindings for more languages. On the client side, the jsolait javascript library contains both JSON and JSON-RPC support, besides other utilities. Characteristics of this approach are: - You can bind methods in javascript to Zope methods, python scripts or page templates and call them up directly from javascript in a synchronous or asynchronous way (RPC). - Both the call parameters and the return value can be strings, unicode strings, instances of any other builtin python data type, or structures built with the combination of tuples, lists and dicts. These get marshalled transparently with JSON. - As a consequence there is no necessity to use XML to pass around structured data, you can just structure your data with python and pass it directly (but of course you also have the possibility to pass around XML). - Passing of both positional and keyword parameters allows to call up page templates with request parameters. - Full client compatibility with the Zope3 version of jsonserver, i.e. the same client code will be able to run on Zope2 and Zope3 without a change. - Five supported. This version, 1.1.pre3 is a pre-release and considered to be beta. It can be installed on Zope 2.7 and 2.8 (for 2.7 you need to install Five). It is compatible with Plone and can be used from it without restrictions. (PLEASE READ release notes for how to fix a critical Plone bug.) More information, download, and installable demo product at http://www.zope.org/Members/ree/jsonserver2 . Please report bugs directly to me. -- Balazs Ree [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] [ANN] mechagen 1.0.beta1 released
Mechagen is a tool for generating automatic Zope2 (and Plone) functional tests for the mechanize framework. The mechanize framework can be used to write Zope2 functional tests in a flexible way and is getting also used in Plone products. However, it lacks support for automatic generation of tests. Mechagen is a tool that adds this support. (zope.testbrowser, zope.testrecorder also offer such a framework. Mechagen was not influenced by them and integration with these libraries will be done only later.) The followings characterize the generation process: - All the tests will be ZopeTestCase based python code, so the integration between traditional (non-functional) and functional tests are complete. There is no need for a separate test runner but the same runner runs all the tests, both functional and traditional ones. - The generator automatically records a given interactive series of requests, and generates a test method from it. Although the generated code can be used as a test without any modification, it should rather be thought of as a template to be edited prior to usage. - The generated tests run in the sandbox provided by the ZopeTestCase framework, which ensures that each test runs independently in the custom environment set up for it. - The interactive recording will go forth in exactly the same sandbox that is designated to run the test later. - The generation process should be easy to use, no extra tools should be necessary and the entire process should be easily manageable from within the test runner environment. You cannot test javascript in your pages with this method, but everything until that. So mechagen cannot replace Selenium but you can do much richer functional testing with it and you can complement these tests with Selenium generated ones. It fully supports Plone. It has a plugin mechanism for extending the generation of checks for your custom page types. The code is beta quality, error reports and comments are welcome. For more information, please visit http://www.zope.org/Members/ree/mechagen . -- Balazs Ree, ree at ree.hu ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] [ANN] jsonserver 1.1.pre2 released (AJAX)
Jsonserver provides an alternative way of AJAX client-server communication on Zope. Jsonserver enables Zope to act as a JSON-RPC server. JSON-RPC is an XML-RPC replacement. It is built on JSON, a javascript based data interchange format. JSON has bindings for more languages. On the client side, the jsolait javascript library contains both JSON and JSON-RPC support, besides other utilities. Characteristics of this approach are: - You can bind methods in javascript to Zope methods, python scripts or page templates and call them up directly from javascript in a synchronous or asynchronous way (RPC). - Both the call parameters and the return value can be strings, unicode strings, instances of any other builtin python data type, or structures built with the combination of tuples, lists and dicts. These get marshalled transparently with JSON. - As a consequence there is no necessity to use XML to pass around structured data, you can just structure your data with python and pass it directly (but of course you also have the possibility to pass around XML). - Passing of both positional and keyword parameters allows to call up page templates with request parameters. - Full client compatibility with the Zope3 version of jsonserver, i.e. the same client code will be able to run on Zope2 and Zope3 without a change. This version, 1.1.pre2 is a pre-release and considered to be beta. It works pretty well but there are things that might need to change before the final release. -- Balazs Ree, ree at ree.hu ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [ANN] jsonserver 1.1.pre2 released (AJAX)
On Thu, 22 Dec 2005 14:19:25 + Martin Aspeli wrote: Jsonserver provides an alternative way of AJAX client-server communication on Zope. This sounds quite interesting. Just wondering if you have any more specific demos, showing how it may be used in a real use case? I agree that there would be need for more demos and I definitely want to work more on them. I already have more use cases for Zope, Plone and Archetypes to be implemented. If anyone has some ideas for good use cases, please let me know. I would be especially happy to have some more plain Zope use cases - since the technology is not limited to Plone. I have also more ideas on how to extend this technology into various directions but this exists only on a theoretical level. -- Balazs Ree ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] [ANN] jsonserver 1.1.pre2 released (AJAX)
Jsonserver provides an alternative way of AJAX client-server communication on Zope. Jsonserver enables Zope to act as a JSON-RPC server. JSON-RPC is an XML-RPC replacement. It is built on JSON, a javascript based data interchange format. JSON has bindings for more languages. On the client side, the jsolait javascript library contains both JSON and JSON-RPC support, besides other utilities. Characteristics of this approach are: - You can bind methods in javascript to Zope methods, python scripts or page templates and call them up directly from javascript in a synchronous or asynchronous way (RPC). - Both the call parameters and the return value can be strings, unicode strings, instances of any other builtin python data type, or structures built with the combination of tuples, lists and dicts. These get marshalled transparently with JSON. - As a consequence there is no necessity to use XML to pass around structured data, you can just structure your data with python and pass it directly (but of course you also have the possibility to pass around XML). - Passing of both positional and keyword parameters allows to call up page templates with request parameters. - Full client compatibility with the Zope3 version of jsonserver, i.e. the same client code will be able to run on Zope2 and Zope3 without a change. This version, 1.1.pre2 is a pre-release and considered to be beta. It works pretty well but there are things that might need to change before the final release. It can be installed on Zope 2.7 and 2.8 (for 2.7 you need to install Five). It is compatible with Plone and can be used from it without restrictions. More information, a simple demo product and download at http://www.zope.org/Members/ree/jsonserver2 . Please report bugs directly to me. -- Balazs Ree, email: ree at ree.hu ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Re: ZAjax anyone?
On Mon, 10 Oct 2005 23:28:03 +0800 Bakhtiar A Hamid wrote: we have zope (dtml/script/zsql-method) that do specific calls that spits out results via xmlrpc. on the browser side, we have all these ajax libs - openrico, dojo, mochikits, azax, DataRequestor, jsolait, tim morgan's mini, etc we just need to connect the dots. the ajax lib + our java functions/etc will call dtml/script/sql-method via xmlrpc(builtin) or jasonrpc(with the jsonrpc product) and page will be updated inline(?) not much voodo involved. everything is there already. a simple demo is at http://myzope.kedai.com.my/blogs/kedai/demo/; a script python that just spits out DateTime().pCommon(), and the other, a script python tah calls html file randomly. replace that with anythin we want. zope rox! but i guess we all know that Thanks, this was a nice briefing. I like the demos, and as a single additional comment I would add that for json-rpc I myself too made some (although more crude looking) simple demos, that do not have a live server but that are installable: so that you can start playing with it on your own server and modify any client or server scripts, if you install the demo + jsonserver2 into Zope as two individual products. Downloads: http://www.zope.org/Members/ree/jsonserver2_pkg/ Guide for the demos: http://www.zope.org/Members/ree/jsonserver2_exa -- Balazs Ree ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: JSON for Ajax applications
Fri, 23 Sep 2005 12:27:34 +0200 keltezéssel Jean-Marc Orliaguet azt írta: Max M wrote: I don't know how many has seen this, but it's pretty cool. JSON (JavaScript Object Notation) is a lightweight data-interchange format. http://www.crockford.com/JSON/index.html It is used for Ajax applications to transfer data instead of xml. It uses repr() versions of standard python objects like dicts, lists, string, numbers etc. to transfer data. It is really simple to generate for Python programmers, so it is very simple to use in Zope too. this is used at 100% and more in cpsskins for Zope3 (cf. z3lab.org). You might also have a look at Jim Washington's 'jsonserver' for Zope3 and its implementation for Zope2 http://zif.hill-street.net/jsonserver I would add that I made up the Zope2 server implementation, sorry I did not announce it on the list. Works perfectly for Zope and Plone. It is currently tested only with Zope 2.7, did not try it on 2.8. You can read more about the Zope2 implementation and download it at: http://www.zope.org/Members/ree/jsonserver2 I also added some simplistic but fully functional examples that help you start with it. I would encourage everyone using it for Zope/Plone. In case of bugs or suggestions, please mail directly to me. I also plan to make some minor update to catch up with newest version of jsolait, as soon as I have some free time. Also I would like to add some yet simple but more real-life examples that would also include usage with Zope, Plone and Archetypes. If you have any good idea for this, please also write to me. Thanks, -- Bala'zs REE' jabber + email: [EMAIL PROTECTED] ICQ: 75955071 AIM + skype: reebalazs ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: [Proposal] Drop Mount.py from ZODB 3.5
Thu, 02 Jun 2005 19:38:02 -0400 Tim Peters wrote: We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's standalone ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ... Although this is not strictly an answer to the original question, I would take to opportunity to react and in the end ask for your opinion. I am asking this because I yet do not see entirely clear in the question of mounting; however, as you will see below, I could achieve my goal in a way. First, according to how much I see of it you are right that Mount.py does not belong to ZODB, and I personally would not even consider using this code for a standalone ZODB app since there are cleaner solutions to be considered. But, as far as Zope is concerned, I have to admit of just having used this code in an app that is currently under development. And here is my use case: The application in question is a complete re-write of an already existing zope application. Migration of the old data to the new application is a key question. There are several backups of the old data at hand that are made by repozo and that can be converted into Data.fs format. The initial migration of the data starts with mounting one of this Data.fs files into the filesystem of the new product, and then migrating the content from it to the new portal. Furthermore, I made testcase base classes for unittest that support migration by using any of the Data.fs files. This way I can have a sequence of migration sources stored in a directory and use automated tests to either test the migration from all of these sources, or I can pick any of the sources, migrate them and run my acceptance tests on the migrated content that is getting formed in the new application. Needless to emphasize the enormeous advantage that I gain with this in the flow of the development, and concerning the success of the future sharp migration that will have to work like a charm on the live system. So far for the case. As for the implementation, since the name of the Data.fs and the mount point are coming from parameters, I could not use the new dbtab style mechanism since these parameters cannot be statically defined in the configuration files. So I decided to subclass the MountPoint class and created a product that mounts a given Data.fs readonly to the given mount point. Now I would like to pose a question to all of you. I am of course not worried if Mount.py is getting phased out completely, since I would be able to take over the code from it into my subclass. But according to my use case described above, am I on the right track with my implementation? Or (supposing that Mount.py disappears) what would be the canonical way of achieving what I want from within Zope? -- Bala'zs REE' jabber + email: [EMAIL PROTECTED] ICQ: 75955071 AIM: reebalazs ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Strange lockup during functional tests (sandboxed)
Hi,
I'm running Zope 2.7.5-1, python 2.3.5-2 and experience that during the
runnig of my own functional tests (sandboxed) after a few tests the
program locks up (CTRL-C does not work, CTRL-Z yes).
I can reproduce the issue with the following test:
---
from Testing import ZopeTestCase
ZopeTestCase.utils.setupCoreSessions(ZopeTestCase.Zope.app())
class TestSessionBug(ZopeTestCase.Functional, ZopeTestCase.ZopeTestCase):
'''
This locks up in the start of test07! The checkpoint is
never reached.
'''
def afterSetUp(self):
print 'Checkpoint'
request = self.app.REQUEST
sdm = self.app.session_data_manager
request.set('SESSION', sdm.getSessionData())
self.sessipn = request.SESSION
def test_01(self): pass
def test_02(self): pass
def test_03(self): pass
def test_04(self): pass
def test_05(self): pass
def test_06(self): pass
def test_07(self): pass
def test_08(self): pass
def test_09(self): pass
def test_10(self): pass
def test_11(self): pass
def test_suite():
from unittest import TestSuite, makeSuite
suite = TestSuite()
suite.addTest(makeSuite(TestSessionBug))
return suite
--
The setup of the sessions in the above code triggers the problem but it
might not be its direct reason. Even without this it happens in some of
my test methods. The lockup is very deterministic and it does not seem to
have much to do with the test methods themselves, that is, if I just run
the test method where it broke, it does not occur.
What am I missing? Can someone reproduce this?
--
Balazs REE
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
