Log message for revision 41297:
Collector #1992: unified visible hostname/ip address during the startup
phase for FTP and HTTP servers
Changed:
U Zope/trunk/lib/python/ZServer/medusa/ftp_server.py
-=-
Modified: Zope/trunk/lib/python/ZServer/medusa/ftp_server.py
Log message for revision 41300:
Partially-working new instructions for running the tests.
The functional tests don't even try to run, but at least this
exercises 6724 of the unit tests.
Someone who understands how Zope3 testing was changed to work
from a zpkgtools-based install
Log message for revision 41301:
Stop hiding the line that builds version.txt.
Don't know why it was hidden before, but can't think of a
reason, and the lack of makefile output showing its creation
just confused the heck out of me for 10 minutes ;-).
Changed:
U
Log message for revision 41302:
DTML Z2 - z3 migration
Changed:
A Zope/branches/ajung-dtml-migration/
-=-
Copied: Zope/branches/ajung-dtml-migration (from rev 41301, Zope/trunk)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
Log message for revision 41303:
When a database is created by hand from a custom_zodb.py during
startup, we still want to put it in the dbtab multidatabases dict.
This happens when unit tests call Zope2.startup(), because Testing has a
specific custom_zodb.py loaded at startup that uses
Tim Peters wrote:
Log message for revision 41291:
Pain, pain, and more pain.
The build-the-installer process now completes, and running
the installer creates something that may or may not be a
working Zope. It starts fine as a Windows Service, and at
least looks like a Zope
Summary of messages to the zope-tests list.
Period Thu Jan 12 12:01:01 2006 UTC to Fri Jan 13 12:01:01 2006 UTC.
There were 8 messages: 8 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:01:50 EST
Andreas Jung wrote:
Thoughts?
All these changes seem to be the right thing. This will make unicode
life in Zope a lot easier.
I worry about backward compatibility though.
Some code (such as PlacelessTranslationService) is doing wild things
like monkeypatching the ZPT engine so that
Andreas Jung wrote:
--On 5. Januar 2006 12:47:20 +0100 Andreas Jung [EMAIL PROTECTED]
wrote:
As you might know I worked on the integration of the Zope 3 ZPT
implementation for Zope 2.10. Before commiting the changes to the trunk I
would like discuss my approach for Zope 2.10
I forgot to
--On 13. Januar 2006 13:25:19 +0100 Martijn Faassen [EMAIL PROTECTED]
wrote:
Andreas Jung wrote:
Thoughts?
All these changes seem to be the right thing. This will make unicode life
in Zope a lot easier.
I worry about backward compatibility though.
Some code (such as
Andreas Jung schrieb:
...
Now, if I have code that takes something from that request and displays
it in a unicode page template, you'd have a problem, as you'd be mixing
UTF-8 with unicode there. Again this might result in a lot of broken
code.
I share your worries (meanwhile :-)).
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux
zc-buildbot.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2750
Blamelist: andreasjung,anguenot,efge,mkerrin,oestermeier,tim_one,ykomatsu
BUILD FAILED: failed test
sincerely,
-The
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2751
Blamelist: andreasjung,efge,tim_one,ykomatsu
BUILD FAILED: failed test
sincerely,
-The Buildbot
[Sidnei da Silva]
Way to go Tim! You beat me to it. I was supposed to look at this soon
but got back from vacation just this tuesday. I will make sure your
installer gets testing and try to fix any eventual issues.
Excellent! This may actually work ;-)
While I'll be on vacation the next two
[Philipp von Weitershausen]
It seems that 'inst' holds nothing of value anymore except 'Makefile.in'
and 'WinBuilders'.
WRT Windows, that's certainly true on my Windows-installer branch. I
don't know whether any of it is still useful on Linux. You seem to
think Makefile.in is still useful,
On Fri, Jan 13, 2006 at 03:13:17PM -0500, Tim Peters wrote:
| I'd rather just remove the decoys. The process of building a Windows
| installer needs/creates three not-checked-in directories that are
| siblings of WinBuilders, and it's nicer to have those hiding under
| inst/ than cluttering the
[Sidnei da Silva]
I think there's a Makefile.win too, that is used by inst/configure.py
on Windows. (I know because use it).
There is a Makefile.win.in, but the build-the-Windows-installer
process no longer uses it on my branch -- the branch doesn't use
anything in the root of inst/ anymore,
Andreas Jung wrote at 2006-1-10 11:23 +0100:
...
Do we need one for Zope 2 and Zope 3?
I think what we discussed during breakfast would be optimal:
To configure the Python logger such that:
* it supports additional (Zope2/3 standard!) log levels
* displays Zope tracebacks rather
Andreas Jung wrote at 2006-1-9 18:06 +0100:
...
I've never had the need to use them. That's different from not wanting to
use them. The more choice you have, the more trouble you have. I agree that
a TRACE level might be of interest. But BLATHER and PROBLEM is competely
overhead from my point of
[EMAIL PROTECTED] wrote:
I'm pretty sure this works.
Ok, I get it now. I misread it the first time.
This returns the equivalent of running
self.objectIds(spec=self._mt_index.keys()) on the current
trunk/release code, which should be identical to
self._tree.keys(), but much, much
Tim Peters wrote:
It seems that 'inst' holds nothing of value anymore except 'Makefile.in'
and 'WinBuilders'.
WRT Windows, that's certainly true on my Windows-installer branch. I
don't know whether any of it is still useful on Linux. You seem to
think Makefile.in is still useful, but if
Håkan Johansson wrote:
On Jan 13, 2006, at 00:32, Dennis Allison wrote:
A more usual solution to this issue is to insert a delay after the third
and subsequent failures. You, of course, need a policy for removing the
delay (successful login or N minutes following the last attempt).
Kedar Dash schrieb:
Dear Tino,
Thank you very much for your response. The site screen shot is given
below. Even if I specify the server name the result is the same.
If I assess the site with it ip address http://ip:port/instance
http://%3cip%3e:%3cport%3e/%3cinstance name it
En/na Martijn Pieters ha escrit:
On 1/12/06, Luca Olivetti [EMAIL PROTECTED] wrote:
Everything has been working fine (apart for the breakage of
CMFQuickInstaller) but I wonder if this is the intended behavior and if
there is better way to update the information in Control_Panel (touching
On Wed, Jan 11, 2006 at 03:00:43PM -0700, David Bear wrote:
thanks for the info. I went and actually read the help text on the
import/export screen where it states:
==
You may import Zope objects which have been previously exported to a file,
by placing the file in the import
We are running Zope 2.6.x and I noticed yesterday that I could do the
following:
acl_users = container.acl_users
user = acl_users.getUser('test_user')
request.set('AUTHENTICATED_USER',user)
print request.AUTHENTICATED_USER.getUserName()
This isn't a huge deal since it doesn't seem to
Bruno Grampa wrote at 2006-1-10 23:42 +0100:
if i upload an image in the ZOBD as a file i have the precondition if i
do the same in the localfs folder no. Do you know why?
The files in an localfs folder are only temporarily wrapped
as Zope objects. The wrapper is destroyed at the request end.
Patrick DECAT wrote at 2006-1-10 15:41 +0100:
I just upgraded my application from Zope 2.8.5 to Zope 2.9.0 and
noticed that PythonScript doesn't support CR/LF line endings anymore
(a la Windows).
Converting my scripts to the Unix format fixes the problem.
Is this new behaviour intented ?
I know
Bruno Grampa wrote at 2006-1-9 23:39 +0100:
i'm building a site to sell images (this is the concept, the reality is
different...).
All the images are in a directory mapped through LocalFS product.
For every image i have a record in a SQL table with all the basic
informations: author, name of the
Luca Olivetti wrote at 2006-1-12 14:55 +0100:
A while ago I changed the directory of my zope instance. I also changed
the zope directory (started with zope 2.8.1, now running 2.8.4). Today I
noticed that the CMFQuickInstaller failed to get the version and the
readme of various products.
It
Andreas Jung wrote at 2006-1-10 06:59 +0100:
...
A single Python process also a multi-threaded Python application can never
run on multiple CPUs.
This means as long as it continues executing Python code.
However, Python often calls non Python code (e.g. C or C++ implemented
extensions) and it
On 1/13/06, Dieter Maurer [EMAIL PROTECTED] wrote:
Patrick DECAT wrote at 2006-1-10 15:41 +0100:
I just upgraded my application from Zope 2.8.5 to Zope 2.9.0 and
noticed that PythonScript doesn't support CR/LF line endings anymore
(a la Windows).
Converting my scripts to the Unix format fixes
Hello
How could I retrieve the path to the config file used to start a running
instance?
I want to put other config stuff in the same directory, and I would like a
safe way to obtain such directory.
I could use INSTANCE_HOME/etc but since the config file name can be
specified in the command
Hi,
we just installed Zsyncer 0.7.1-beta1 on a couple of our servers and
have run into some problems with page template synchronization. Some
items that have different time stamps on the server and on the
development machines show on th sync screen as synchronized even when
they are different.
On 1/13/06, Gabriel Genellina [EMAIL PROTECTED] wrote:
How could I retrieve the path to the config file used to start a running
instance?
I want to put other config stuff in the same directory, and I would like a
safe way to obtain such directory.
I could use INSTANCE_HOME/etc but since the
Hv u try using the ZSearchInterface calling your ZSQL method (below). Try it. It will solve your problem except the layout is not good looking. Hiowever, you may to modify it to pass arguments to your ZSQL method. Look for: dtml-if previous-sequence a href="" (Previous dtml-var
--On 13. Januar 2006 11:12:22 +0100 Michele Simionato
[EMAIL PROTECTED] wrote:
I have discovered that the values in the dtml-comment are not honored:
so if I change max_rows_ to a different value nothing happens.
Zope always retrieve up to 1000 rows, which is the default value
fixed
On 1/13/06, Andreas Jung [EMAIL PROTECTED] wrote:
Because it must be max_rows: 1000.
-aj
You mean without the tralining underscore in the dtml-comment?
So I should change
dtml-comment
title:
arguments:
connection_id:rcare_connection
max_rows:1000
max_cache:1000
cache_time:86400
class_name:
For the record, removing the trailing underscore worked. Damn FSDump!
Thanks for the help.
Michele Simionato
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
Martin Krallinger wrote at 2006-1-10 16:57 +0100:
thanks for the info. I am actually using zope 2.7 but still I
encountered this problem.
I think the poster wrote: fixed in Zope 2.7.
Maybe, you try 2.8.5 or 2.9?
--
Dieter
___
Zope-DB mailing list
[EMAIL PROTECTED] wrote at 2006-1-12 15:03 +0100:
After creating about 20 ZSQL Methods and polishing them out,
I tried some changes in opt/Zope-2.8/lib/python/Shared/DC/ZRDB which
worked fine.
But then these Objects all appreared like this:
Abrechnung (This object from the ZSQLMethods product is
41 matches
Mail list logo
