We're using dual cpu (not dual core) 64bit AMD Opteron (Sun Fire V20's)
based systems and are VERY impressed with their performance; our python
benchmarks show dual Opteron 250 systems outperforming dual twin-core
Xeon 3.6GHz with the same code. Almost everything we run is ZEO based
and hosted
Tim Peters wrote:
[Sune B. Woeller]
...
I can see (with the excellent (and free) 'Process
Explorer' from sysinternals) that the python
processes always opens port 1, and connects by
that port to themselves on another port (for
instance 2550).
[Dieter Maurer]
You can find the
[Sune Brøndum Wøller]
Thanks for the pointer. I have been debugging
select_trigger.py, and has some more info:
The problem is that the call a.accept() sometimes hangs.
Apparently a.bind(self.address) allows us to bind to
a port that another zope instance already is bound to.
The code
Itai Tavor wrote at 2005-7-26 11:20 +1000:
...
Couldn't get it to work, though... not sure why: unicode('\u2013')
returns u'\\u2013', which is useless.
I know why (now, that you report the problem).
'...' introduces a non unicode string in which \u is not recognized.
\u is only recognized
Asad Habib wrote at 2005-7-25 15:19 -0400:
...
socket.gethostname() is not
returning the full canonical name of the machine.
gethostname is not required to return the FQDN (Fully Qualified Domain Name).
This is not your problem.
But gethostbyname(gethostname()) should be able to resolve
(Sorry about the lateness of this post, a combination of interesting SMTP
blocks + Zope mailing list policies made this message not come through the
first time around, which was the 20th of July. I discovered this today
while browsing the archives.)
On Wed, 20 Jul 2005 01:07:25 +0200, Rob
--On 26. Juli 2005 22:40:18 +0200 Alexander Limi [EMAIL PROTECTED] wrote:
They did the work on our behalf, and most excellently executed the
worldwide registration of the mark. The trademarks were transferred fully
to the
Plone Foundation as agreed.
So any idea why the WIPO database tell us
Hello,
I'm currently hacking the ZODB, and I've found that the close() method in DB.py
which call close() on FileStorage is never called.
Is this a bug ?
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No
[EMAIL PROTECTED] wrote at 2005-7-26 11:40 +0200:
I'm currently hacking the ZODB, and I've found that the close() method in DB.py
which call close() on FileStorage is never called.
Is this a bug ?
Yes, looks like a bug
As a consequence, the index file of ZODB.FileStorage.FileStorage's
is not
Say I have a user in a root acl_users folder (call it 'admin'). I also
have a PAS user folder in a sub-object of the root. This PAS is
configured to do cookie auth, and users will typically login using a form.
Now, if I try to log in as 'admin' in that form, it doesn't work. I
think this is
10 matches
Mail list logo
