Sidnei da Silva wrote:
C:\Python24
C:\Zope\2.10.0 (NB: C:\Zope\2.10.0\Zope would NOT exist)
Should we go for Zope210 since Python is Python24?
Nah, I like having C:\Zope\* as I always have several Zope versions on
the go.
I wish python would switch to C:\Python\2.4, but that's probably a
Sidnei da Silva wrote:
Just as a note, those are pretty 'Advanced' applications. OTOH, Zope
is too. So I buy your argument.
Yay :-)
What's your proposal for default Installation and Instance directories?
I borrowed Guido's time machine an answered this already in another
message ;-)
- w
Hi Sidnei,
I don't know how easy this is to do, but one thing that would be
_really_ nice would be to use an existing compatible python install
rather than Zope splatting it's own in regardless.
In fact, if we're re-doing the layout (which is, I think, a VERY good
idea) my ideal layout would
Sidnei da Silva wrote:
Hi Christian(s)!
I know most people dislike . I do too! But it's the
closest we have to a 'standard' place for installing applications.
It's not the 'standard'. To name a few examples, all of Python, Lotus
Notes and, perhaps most tellingly, IIS and Microsoft's other ser
Sidnei da Silva wrote:
Since I saw this, I've changed the default directory to Files>\Zope\2.9.5.
Bleugh. I hate "Program Files" :-(
There will be two sub-directories here, 'Zope' and
'Python'. This is so Python is not buried inside a 'bin' directory.
yay :-)
What would be a good default
Sidnei da Silva wrote:
I would like to know if anyone has multiple Zope installations on
Windows side-by-side and if they consider that important.
Well, I do that all the time, I have:
C:\Zope\2.7.3
C:\Zope\2.7.8
C:\Zope\2.9.1
C:\Zope\2.9.3
C:\Zope\2.9.4
...and then lots of instances, which s
Christian Steinhauer wrote:
since month there is no new windows build of the zope2 releases. It would be nice if someone can make a decision who can take care of the build for the windows version.
No one can force someone to do this, we need a volunteer. I was happy
doing it but I don't have a
Wolfgang Strobl wrote:
I'll have to stay with 2.9.4 or older, for the forseeable future. Somehow, I
wonder whether current Zope2 releases get any real world testing before becoming
"stable". Did perhaps all testing happen on the Windows side, in the past? ;-)
Er, no. You'll likely find that
Hi All,
I've been having fun with unit tests:
http://mail.zope.org/pipermail/zope3-dev/2006-October/020757.html
http://mail.zope.org/pipermail/zope3-dev/2006-October/020775.html
But Jim finally pointed me in the right direction:
http://mail.zope.org/pipermail/zope3-dev/2006-October/020789.htm
There still appear to be some outstanding dns issues...
Chris
Wichert Akkerman wrote:
Is something happening with svn.zope.org? I haven't been able to use
anonymous or authorized svn for two days.
Wichert.
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.
Sidnei da Silva wrote:
I'm using Zope on Windows on a daily basis now. So that might mean me. :)
Well volunteered :-)
I would point you to the right place to look for the instructions in
svn, but zope.org's dns is currently geB0rken...
I would like to propose setting up some sort of 'nigh
Andreas Jung wrote:
Thanks for your work on the windows builds in the past. We appreciate
your work very much.
I'll 2nd that!
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev ma
Jens Vagelpohl wrote:
I'm afraid I spoke too soon. My sudo access has been removed. Jim tells
me any task requiring root access must be performed by him (or other ZC
staff I presume). I'm hereby "un-volunteering" myself from this task.
That's a shame...
What is it with preventing people who w
Sidnei da Silva wrote:
On Sat, Oct 07, 2006 at 09:25:29AM +0200, Andreas Jung wrote:
| Who is currently in charge or who feels responsible for the Windows builds?
Tim Peters.
Er, no. Tim isn't even at Zope Corp anymore, as far as I know...
I built the last couple of Zope 2.9.x release, but my
Dieter Maurer wrote:
3. If repozo is not to blame, what could be?
One possibility would be a bad call.
A bad call?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist
Hi All,
One of my customers has a large (21GB) production zodb which they back
up onto a contingency server using repozo and rsync. The process is
roughly as follows:
1. pack the production database to 3 days once a day.
2. create a full backup with repozo and rsync this to the contingency
Hi Tina,
Tina Matter wrote:
I have a basic DTML document that has several input fields on it.
I'm pretty sure you're looking for the zope@zope.org list ;-)
On my error page (dtml-document),
Use ZPT instead, or Twiddler when it's out ;-)
However, when I click on that link, my SESSION valu
Jonathan wrote:
BTW - nothing beats ZClasses and DTML for quick-and-dirty demos,
one-time applications, and rapid-prototyping!
I prefer to use page templates, python scripts and PropertyManagers for
this ;-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
-
This probably merits the Zope Dev list too, since this is part of "core
zope"...
cheers,
Chris
FAIRS, Dan, GBM wrote:
Hi,
Under load, we're seeing KeyErrors from the _cached_result method of the DA
class in the code used to clear out cached results. We're using Python
2.3.5, Zope 2.8.5, mxOD
[EMAIL PROTECTED] wrote:
I'm getting a ZODB.POSException.ConflictError in the following code in a
Custom Zope Product,
Google for "ConflictError Zope" and read, a lot. These are to be
expected due to Zope's concurrency model, but if end users are seeing
them then your application needs restru
Tres Seaver wrote:
The other reason for wanting "early binding" to the ports is if the
ports are in the "reserved for root" range (< 1024); in that case, the
ports *must* be bound early, before dropping privileges to those of the
"effective user".
Ah, that's true enough, but then again, anyone
Andreas Jung wrote:
The usecase is pretty simple: you have a loadbalancer and remove one
backend Zope. The LB detects the removal and stops forwarding request.
When the client comes back (means Zope opens the ports early) the LB
will start forwarding to the client although it might take a wh
Christian Theune wrote:
b) it's more convenient for developers
Why?
Early open port means: zopectl restart and reload in your browser
immediately without getting "Connection refused". Dieter already
mentioned this use case
I don't really buy that, but since it's configurable, it doesn't
Christian Theune wrote:
b) it's more convenient for developers
Why?
c) it's a good thing if you have 'smart' load balancers
How so?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Tres Seaver wrote:
Unlike you, I prefer when the browser waits until Zope
has come up over me having to reload manually until it
finally is ready...
The branch Andreas just merged leaves the "fast-bind" option on by default.
Cool, although I can't really see the use ;-)
All this does is let
Jens Vagelpohl wrote:
CMFCore/FSPageTemplate does not do anything special, it defers to the
PageTemplate implementation.
Yay! *sigh*
Uggg... we need something like python's
header-at-top-of-file-to-specify-encoding thing, unless we force ZPT
source to be XML, in which case we can "do the rig
Andreas Jung wrote:
security.declareProtected(change_page_templates, 'PUT')
def PUT(self, REQUEST, RESPONSE):
""" Handle HTTP PUT requests """
self.dav__init(REQUEST, RESPONSE)
self.dav__simpleifhandler(REQUEST, RESPONSE, refresh=1)
## XXX this should be unicode
Andreas Jung wrote:
Zope 2.10 comes with the ZPT implementation of Zope 3 which works nicely
with unicode strings. However the 2.10 won't enforce the use of unicode
strings for backward compatibility. However (at least) the
ZopePageTemplate
class constructor has a flag 'strict' to enforce t
Tino Wildenhain wrote:
This would be my next question too regarding the management_page_charset
cleanup I'm currently playing with. My vote would be to store unicode
where possible - so you dont screw up everything when you change
default_zpublisher_encoding in zope.conf.
Yeah, unicode is good.
Andreas Jung wrote:
I've had problems when it's an encoded string, but that seems to be what
is stored when you save a ZPT via the ZMI or WebDAV...
ZPT in pre-Zope 2.10 knows nothing about unicode...it can be anything :-)
And what about 2.10?
FWIW, this seems to be problematic due to Zope
The subject line says it all really ;-)
I've had problems when it's an encoded string, but that seems to be what
is stored when you save a ZPT via the ZMI or WebDAV...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_
Hi All,
Okay, I'm now using Zope 3's i18n in Zope 2.9.3 but have hit a snag with
Zope 2's ZPT...
Zope 3's translation stuff returns unicode, Zope 2's ZPT seems to work
in encoded strings so, when the list of text items is finally combined
in the last stage of ZPT rendering, I'm getting unico
Jim Fulton wrote:
BTW, I suspect that a less violent patch could be created, if
anyone wants to champion TTW reStructuedText support in
Zope 2. Personally, I'm for dropping it.
+1 on dropping it completely, but then I hate all types of structured
text so I doubt I'm in the majority...
Chri
Max M wrote:
Well, the sooner better...
...this comes mainly from my desire to see the "exponential
combination of branches" problem go away...
Technically speaking, isn't that a squared problem?
That depends how many pieces of software are involved ;-)
Chris
--
Simplistix - Content Manag
Dieter Maurer wrote:
Chris Withers wrote at 2006-6-23 17:12 +0100:
Get this error on startup with one project I've just moved to Zope 2.9.3:
File "/usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py",
line 175, in createDB
return ZODBDatabase.open(self, database
Philipp von Weitershausen wrote:
Jim suggested a different strategy with "Zope 5"
(http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html).
The little bits and pieces that make up Zope 3 (the zope.* packages)
would be developed more or less independently of Zope-the-app-server
(which
Philipp von Weitershausen wrote:
Chris Withers wrote:
Florent Guillaume wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
Zope 2.10 does? It shouldn't. Please point out the deprecation
warnings it sends.
I, like many people I suspect, am
Philipp von Weitershausen wrote:
It's dead from a maintenance point of view. If you still want to
maintain it, be our guest. But you yourself said that maintaining too
many branches is madness.
My point is that we're creating too many branches ;-)
Chris
--
Simplistix - Content Management, Zop
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200:
... deprecation policy ...
This policy allows us to move forward (which Zope 2 never
really did for the the majority of those five years you mention).
Although, it might help in a few cases, it is not at all
necessa
Hi All,
Get this error on startup with one project I've just moved to Zope 2.9.3:
File "/usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py",
line 175, in createDB
return ZODBDatabase.open(self, databases)
File "/usr/local/zope/2.9.3/lib/python/ZODB/config.py", line 105, in ope
Philipp von Weitershausen wrote:
Follow this thread:
http://mail.zope.org/pipermail/zope3-dev/2005-November/016561.html
*grunt* *sigh*
It has to happen at some stage, surely?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
Rob Miller wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
the deprecation warnings in Plone annoy me to no end. unfortunately,
though, Plone (thus far) has chosen to straddle Zope release.
I dunno... some, like zLOG, have been "fixable"
Florent Guillaume wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
Zope 2.10 does? It shouldn't. Please point out the deprecation warnings
it sends.
I, like many people I suspect, am still struggling to get projects onto
2.8/2.9. The thought
Philipp von Weitershausen wrote:
Collector entries can always be rejected if it turns out there is no
bug. This mailinglist thread will be forgotten next week, though. So,
pretty please open a collector issue.
Fine:
http://www.zope.org/Collectors/Zope/2135
Furthermore, I suggest you wrap
thi
Benji York wrote:
Philipp von Weitershausen wrote:
Uh, never mind.
+1 :)
Any chance you could explain why you feel that way?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-De
Andreas Jung wrote:
I for one, is NOT interested in backporting fixed in Five trunk to
both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current
versions of Five if we say that Zope 2.8 and 2.7 should be still
supported after the release of 2.10.
We don't talk about Zope 2.7 which i
As always, Martijn has prettymuch hit the nail on the head with this
mail, +lots to all the points he raises...
Chris
Martijn Faassen wrote:
I think we've concluded a number of things:
* some developers (Andreas in particular) do not consider it a huge
problem to keep maintaining an older v
Martijn Faassen wrote:
Chris Withers wrote:
[snip]
One of my other bugbears is that a flood of deprecation warnings often
masks real problems.
What real problems?
Deprecation warnings in code I need to care about, as opposed to
mindless spew from the zope core or other installed products
Lennart Regebro wrote:
Supporting old versions must reasonably be a community effort,
depending on if people have the time to do so. We can't just say
"three versions should be officially supported" and then not doing it.
Yup, and I think it's safe to say the fewer version we need to support,
Jens Vagelpohl wrote:
Use the collector. It is *the* place where people go to look for things
to fix. What length of time it takes to fix is a totally separate issue.
Bugs that get posted on mailing lists get ignored unless they are "the
world is coming to an end" type bugs.
Read the thread,
Florent Guillaume wrote:
Hopefully the google archive trail will be enough for this issue...
When I look for bugs to fix I don't read the mailing list archives for
the past two years, I use the collector.
Funny, I usually start by googling...
Chris
--
Simplistix - Content Management, Zope
Christian Theune wrote:
However, Zope 2.8 is still available for stable download ... so we
currently have 7 branches to watch out for.
...and you're not even including ZODB branches and the like that need to
be maintained and kept in sync...
Chris
--
Simplistix - Content Management, Zope &
Martijn Faassen wrote:
+1
Extending the maintenance period for older branches indeed sounds like a
good idea.
Hang on, that makes things even worse for the already-stressed
developers though. The branches there are combined with the longer
they're stable for gives you the "developer stress
Philipp von Weitershausen wrote:
Note that this should also extend to the Zope 3 releases. Zope 3.2 is
part of Zope 2.9 and will hence be used for quite some time. Yet,
bugfixes aren't even backported to the Zope 3.2 branch anymore...
It's this sort of thing that makes me wish we could unify th
Martijn Faassen wrote:
Paul Winkler wrote:
On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote:
I think that's the sanest policy. So it's OK if "bullshit" gets
called on people putting deprecation warnings into any .1, .2, etc
through .9 releases, then? This seems like the onl
Lennart Regebro wrote:
On 6/18/06, Paul Winkler <[EMAIL PROTECTED]> wrote:
+1, I'd like some way to easily know when a release is no longer
maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release.
Unless we decide to change tha
Lennart Regebro wrote:
Only because we have more stable releases,
"only"? That's the big problem here ;-)
1. That's all well and good until you _need_ some feature like MVCC and
are then forced to do an upgrade which breaks prettymuch every one of
your products.
And the difference is that t
Florent Guillaume wrote:
If anyone with greater knowledge could implement the above without
much pain, that'd be great. In any case, hopefully Google will catch
this some time and save the next weary traveller who bumps into it a
couple of hours ;-)
How about opening a ticket in the collector
Martijn Faassen wrote:
Chris Withers wrote:
[snip]
Personally, I find non-time-based releases a much nicer prospect: you
only need to move to the next major version when it's ready and
because it contains big new features you really want.
Who is going to develop these big features? W
Tres Seaver wrote:
Unit test coverate for custom products is actually quite good. The
problems are nearly always to do with "third party" products, many of
which have been in "useful stable" mode since long before either
deprectaions or ubiquitous unit testing were part of our community's
develo
Chris McDonough wrote:
An example of cruft removal that is worthwhile: the help system code
has stupid side effects (it writes to an invisible catalog in the ZODB
*at startup!*), and people have an alternate way of viewing the help via
the filesystem. Apparently nobody actually looks at the h
yuppie wrote:
# Support old-style product metadata. Older products may
# define attributes to name their permissions, meta_types,
# constructors, etc.
[followed by the code that interprets the 'methods' attribute]
So 'methods' is BBB code for constructors.
That depends on how y
Hi All,
Got this weird error message:
Module TAL.TALInterpreter, line 701, in translate
Module Products.PageTemplates.TALES, line 261, in translate
Module Products.Five.i18n, line 51, in translate
Module Products.PageTemplates.GlobalTranslationService, line 33, in
translate
TypeError: e
yuppie wrote:
If adding deprecation warnings for 'methods' was a mistake it was not a
simple mistake. I still believe it should be removed.
I think you're in the minority here. I suspect you could remove the
"legacy" thing without much problem, but it feels like "methods" has a
genuine need f
Max M wrote:
Andreas Jung wrote:
At some point you have to make a cut to get rid of old crap. Fixing
the zLOG
issue is a straight forward approach with very little risks for the
programmer and it won't take too much time..I don't see a major
problem with that.
Except that it hits a sore spo
yuppie wrote:
I believe the Hippocratic Oath should be followed in subjective cases
like this. "First, do no harm."
Cruft does harm. It discourages people who want to understand and
improve Zope. And it encourages people to stick to bad coding habits.
As far as "methods" goes, I call bullsh
Lennart Regebro wrote:
So this is not a problem with deprecation period, time based releases
or anything else, then.
No, but the slew of deprecation warnings, proliferation of branches that
need to be supported (regardless of whether they're "officially"
production or not) and sheer amount o
Wichert Akkerman wrote:
Previously Max M wrote:
Andreas Jung wrote:
At some point you have to make a cut to get rid of old crap. Fixing the
zLOG
issue is a straight forward approach with very little risks for the
programmer and it won't take too much time..I don't see a major problem
with tha
Chris McDonough wrote:
checkins list. Yes, I know. I know. I'm bad. But all of you have
been there before, I'm pretty sure, so I hope you can sympathize.
...and how!
And why the should the core emit a deprecation warning?
Amen.
the goal here? Removing zLOG is (at least by any sane mea
Jens Vagelpohl wrote:
Yes, the 6 month cycle is very short. All of a sudden we have a
situation where a whole slew of releases/branches is out there (2.7,
2.8, 2.9, 2.10, trunk)
Indeed, this seems to be purely an artifact of time-based releases. I'm
sure I'm not the only one who routinely has
Andreas Jung wrote:
Right. As a rule we must fix any code in the Zope core that would possibly
spit out a deprecation warning caused by a deprecation warning. At least
for zLOG in Zope 2.9 we (possibly only me) were not totally consequent.
Yes, I noticed your name in "svn praise" ;-)
Chris
Andreas Jung wrote:
For me, the fact that Zope 2.9.3 still emits
deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
Deprecation warning is only annoying but not a bad sign. Deprecations
are not a functional problem.
That sends a pretty bad message. It's not really accept
Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party
product developers have been ignoring the warning. Their loss.
And this is only for Zope 2.10 which I doubt these third party products
are using at the moment.
If we don't remove things at some point
Chris McDonough wrote:
So be it. This is really minor. Not deprecating it is the right thing,
and I won't even qualify that with a "IMO" ;-)
+1
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
__
Chris McDonough wrote:
view, but this wouldn't work for non-URL lookups. So people who use
'methods' now will need to monkeypatch in hideous ways just like the
'methods' stuff does now, in which case why not leave it?
Am I right as reading this as someone else who feels "why are we
deprecati
Florent Guillaume wrote:
Anyway for EE the 'methods' use can be replaced by:
from OFS.Folder import Folder
Folder.externalEdit_ = ExternalEditor()
Folder.externalEditLink_ = EditLink
And this is supposed to be better?!
Until a sane alternative is available, I'd proprose to un-deprecate
these
Dieter Maurer wrote:
M. Krainer wrote at 2006-6-2 12:27 +0200:
Forgot to mention that this was actually the first thing I tried. But it
doesen't work, as
the INSTANCE_HOME dir does also not show up in sys.path (in find_globals).
A ZEO weakness, I fixed in our local copy this way:
"runzeo.py":
Out of interst, why not just make this change wherever empty tales
expreessions have been used in the past?
It'd be clearer as to what the intention was and remove the necessity
for hacky code like this...
cheers,
Chris
Florent Guillaume wrote:
Log message for revision 68462:
Merged r684
Florent Guillaume wrote:
Current bare Zope 2.10 sends some deprecation warnings because it itself
imports things that it deprecates, this will have to be hidden.
Suggestions welcome:
- App/Product.py imports ZClasses which are deprecated,
Does it really need to?
- Products/ZCatalog/ZCatalog
Philipp von Weitershausen wrote:
maintained in Zope 3. Plus, the goal is to use the Zope 3 implementation
everywhere so there must be some advantages in the Zope 3 implementation
over the Zope 2 one... otherwise we wouldn't be doing this...
This logic is faulty. The merge is desirable because i
Philipp von Weitershausen wrote:
So, even though Chris Withers and you like the parallels to a Unix
shell, they're not even reality as of Zope 2.9.
Sorry, you're completely right and I'm mistaken, my apologies.
In TALES you always start from an object, so I'm +1 on bannin
Tres Seaver wrote:
+@deprecate("The 'last' method has been deprecated and will disappear "
+ "in Zope 2.12. Use the 'end' property instead.")
def last(self, name=None):
if self.end:
return True
I don't think deprecating 'first' and 'last' is appropr
Tres Seaver wrote:
Zope2 uses them at the beginning of a path to indicate traversal from
the root. -1 to dropping that case (it is the one which makes
'/foo/bar' behave orthagonally).
Yeah, I'm actually about -10 to this ;-)
...think about trying to explain why:
context.restrictedTraverse(
I know it's an old Zope version, but it doesn't look like the code's
changed in this area since then...
Should it be possible for the following to happen?
File "C:\Zope\2.7.6\lib\python\Products\ZCatalog\ZCatalog.py", line
558, in uncatalog_object
self._catalog.uncatalogObject(uid)
Fi
Duncan Booth wrote:
What may be more significant is that simply retrieving favicon.ico into IE
displays garbage. I don't know why; IE seems perfectly capable of
displaying it on the address bar or favourites, but in the main browser
window it displays a short curved line and nothing else.
Is
Hi All,
Any idea what's causing the svn failrues on the buildbot.
This only seems to be affecting the Windows builds, with the Zope 2 & 3
trunk not currently building...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_
Benji York wrote:
Yep, that looks like it. Either I'll make my first commit to Zope 2
ever :) or if you want to, you can change it to something like this:
import tempfile
import os
fname = 'import_export.xml'
tempdir = tempfile.mkdtemp()
try:
ostream = open(fname, 'wb')
try:
d
Benji York wrote:
2000--Zope---branches---2.9--2.4\build\lib\python\OFS\tests\test_XMLExportImport.py",
I suspect the following pattern needs to be changed:
ostream = tempfile.NamedTemporaryFile(suffix='.xml')
try:
data = exportXML(connection, oid, ostream)
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
Several components that we'd like to use in Zope2, such as the
SequenceEngine from Zope3,
That's meant to say SequenceWidget, and we already *are* using it in
Five, so not supporting request.debug would mean dropping support for
Lennart Regebro wrote:
I also recommend that we deprecate both __bobo_traverse__ and
__browser_default__, but perhaps with a longer derecation period that
usual, since this are very basic techniques used in many products.
Please discuss. :)
-1 - what's wrong with having the default adapter arou
Philipp von Weitershausen wrote:
in memory. Dieter estimates 20% to 35% slowdown for the C algorithms
(whatever that means), Tim seems to think it won't have such a big
effect. I guess we'll only know after some benchmarks.
Can we please not make any definite decisions until this issue has been
Fred Drake wrote:
(possibly named LLBTree, LOBTree, and OLBTree).
For my half-penny's worth, this is the way I'd like to see it go.
Explicit is better than implicit and all that.
If you need more than 32-bits, you can explicitly use them.
The implicit change to make them all 64-bits which res
Hi Dirk,
I'm CC'ing in zope-dev as more people there may care...
Dirk Datzert wrote:
Hi Chris,
you wrote on the ZOPE-DB mailing-list
http://www.mail-archive.com/zope-db@zope.org/msg00417.html at Fri, 24
Feb 2006 09:15:31 -0800.
I have seen this KeyError after updating from Zope 2.7.5 to Zo
Hi All,
I'm currently plagued by the following annoying:
ZODB Could not import class 'BTree' from module 'BTree'
What's the recommended way of tracking these down?
Is there anything we can do to make the logged message give more info
about where the object is?
I eventually stab-in-the-dark'e
Stefan H. Holek wrote:
This is an old ZODB, right?
Yup, from Zope 2.7.6
ZGlobals is used by ZClasses. There used to be a time when ZGlobals was
still a BTree when it should have been a BTrees.BTree. Then some
migration code was added.
It obviously never kicked in ;-)
I suppose the error
Hi All,
I see this intermittently on startup:
2006-04-03 21:21:37 ERROR Zope.ZODBMountPoint Failed to mount database.
exceptio
ns.ValueError (database_name 'packed' already in databases)
Traceback (most recent call last):
File
"C:\Zope\2.9.2\lib\python\Products\ZODBMountPoint\MountedObject.
I see the following the first time a Zope instance is started under 2.9:
2006-04-03T10:59:30 ERROR Zope A problem was found when checking the
global product registry. This is probably due to a Product being
uninstalled or renamed. The traceback follows.
Traceback (most recent call last):
F
Tres Seaver wrote:
I don't get what you mean: FilesystemSite *is* a separate packaging of
the DirectoryView /FS{DTMLMethod/PythonScript/PageTemplate/SQLMethod}
stuff, without any CMF dependencies.
Yes, exactly, there are several of them. Usually forked off from CMF's
DirectoryView at some poi
Mark Hammond wrote:
If this is the problem, it will probably only happen when using
runzope.bat - running as a service probably works fine.
Ah, okay, yeah, I only use runzope...
In that case, the problem is the order that Windows uses to search for DLLs.
The short answer is that things should
Hi Mark,
I see you replied, but I missed this first time round:
http://mail.zope.org/pipermail/zope-dev/2006-March/027166.html
> What version of pywin32 did you use for the build?
http://svn.zope.org/Zope/trunk/inst/WinBuilders/README.txt?rev=65838&view=auto
...shows the exact list of inst
601 - 700 of 2150 matches
Mail list logo
