[Zope-dev] Removing 'inst'

2006-01-13 Thread Philipp von Weitershausen
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 ;-)

All hail Tim Peters! :)

   Nothing in the build-the-Windows-installer process here
   uses anything in the root of the inst/ directory anymore.
   Instead the WinBuilders zope.mk builds Zope all by itself,
   using the Python created by python.mk.  Everything these
   used to use in the root of the inst/ directory was so out
   of whack with current reality that there was no point even
   trying to reverse-engineer what it thought it was doing.

It seems that 'inst' holds nothing of value anymore except 'Makefile.in'
and 'WinBuilders'. I propose moving those two items to the root and
remove 'inst'.

Philipp
___
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] Zope tests: 8 OK

2006-01-13 Thread Zope tests summarizer
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 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/003994.html

Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:03:20 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/003995.html

Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:04:50 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/003996.html

Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:06:20 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/003997.html

Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:07:50 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/003998.html

Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:09:22 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/003999.html

Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:10:52 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004000.html

Subject: OK : Zope-trunk Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:12:22 EST 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004001.html

___
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] [Zope 2.10] ZPT going Unicode

2006-01-13 Thread Martijn Faassen

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 incoming unicode is encoded 
into UTF-8 during page template execution. I.e. the principle is quite 
different from that of Zope 2 itself, where the publisher takes care of 
translating things into an encoded string upon output. Since Silva 
doesn't use PTS anymore I don't worry about this, but Plone developers 
might.


Changing the default encoding of Zope to UTF-8 might break a lot of 
assumptions in people's code.


What about input? If I have an input form, browsers tend to submit in 
the encoding that the form as in, for instance UTF-8. This means I get 
UTF-8 strings into my request.


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.


Regards,

Martijn
___
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] [Zope 2.10] ZPT going Unicode

2006-01-13 Thread Martijn Faassen

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 mention a major point: compatibility.

When a ZPT is internally stored a unicode string then content returned 
by methods called through the ZPT will be implicitly  converted to unicode.
This will definitely raise UnicodeDecodeErrors. So how to deal with this 
issue?


Ah, I wrote my reply before reading this.


- allowing only unicode textual content when calling macros, PyScript etc.

- converting non-unicode to unicode inside the TAL code using some
  encoding. The encoding could be specified as property of the called
  method (function properties) or object.


In effect Python already does this, it just decodes to unicode using a 
strict ASCII encoding. Making this configurable per page template might 
be good, though I'm worried about supporting implicit behavior leading 
to bad coding patterns. I'd prefer code to be Python unicode clean, but 
allowing in, say, UTF-8 strings, into a page template and then 
implicitly converting them to unicode, is inviting people to persist in 
not understanding the way to write good unicode code.



We really _need_ to discuss this issue early to minimize side effects
and to be able to provide the best compatibility possible.


Agreed!

Regards,

Martijn

___
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] [Zope 2.10] ZPT going Unicode

2006-01-13 Thread Andreas Jung



--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 PlacelessTranslationService) is doing wild things like
monkeypatching the ZPT engine so that incoming unicode is encoded into
UTF-8 during page template execution. I.e. the principle is quite
different from that of Zope 2 itself, where the publisher takes care of
translating things into an encoded string upon output. Since Silva
doesn't use PTS anymore I don't worry about this, but Plone developers
might.

Changing the default encoding of Zope to UTF-8 might break a lot of
assumptions in people's code.

What about input? If I have an input form, browsers tend to submit in the
encoding that the form as in, for instance UTF-8. This means I get UTF-8
strings into my request.

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 :-)). Enforcing unicode is too strict. I 
think to relax the wrapper code so it can handle both unicode and 
non-unicode (for backward compabitlity)...possibly using some 'strict' flag 
that enforces the use of unicode...I just don't know yet how to add this in 
a same way.


Andreas



pgpBiFEn5d6BD.pgp
Description: PGP signature
___
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] [Zope 2.10] ZPT going Unicode

2006-01-13 Thread Tino Wildenhain
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 :-)). Enforcing unicode is too strict. I
 think to relax the wrapper code so it can handle both unicode and
 non-unicode (for backward compabitlity)...possibly using some 'strict'
 flag that enforces the use of unicode...I just don't know yet how to add
 this in a same way.

Maybe just have new uZPT with Unicode and leave the old ZPT allone?
Maybe with limited ability to add old ZPT from ZMI or such.

This would solve the backward-compatibility problems and would be a more
smooth transition w/o the need of upgrade hacks and strict hacks
(after all, we arent perl/php ;))

Maybe with a make all my ZPT uZPT or the like for the real desperate.

++Tino
___
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] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot

2006-01-13 Thread buildbot
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 Buildbot

___
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] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

2006-01-13 Thread buildbot
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

___
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: Seeking brave souls to try Zope 2.9 Windows installer

2006-01-13 Thread Tim Peters
[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 weeks, I'll check email each
day, and will be happy to give minor wink help with mysteries.  The
build-the-installer code got substantially simpler, but I think it's
hard to jump in cold and understand it (in part because the
makefile-maze infrastructure is better suited to more complicated jobs
than this one has become).  WinBuilders/README.txt is the best place
to start, and I tried to leave it telling only truths on the branch.
___
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] Removing 'inst'

2006-01-13 Thread Tim Peters
[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, but if that's true then I expect
inst/configure.py is also still useful (it looks like configure.py is
the intended way to create an actual makefile from the Makefile.in
template).

One thing for sure is that it will be helpful to get rid of as many
decoys as possible; e.g., I burned several hours staring at the stuff
in inst/ wondering how to make it work again, then digging in to why
it existed at all, and finally concluding that everything it ever did
is of no use on Windows anymore ;-).

 I propose moving those two items to the root and remove 'inst'.

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 root of a checkout.

The Windows stuff will have no use for anything other than
WinBuilders/, so if Makefile.in's Linux purpose would be better served
by moving that elsewhere, that would be fine.
___
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] Removing 'inst'

2006-01-13 Thread Sidnei da Silva
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 root of a checkout.
| 
| The Windows stuff will have no use for anything other than
| WinBuilders/, so if Makefile.in's Linux purpose would be better served
| by moving that elsewhere, that would be fine.

I think there's a Makefile.win too, that is used by inst/configure.py
on Windows. (I know because use it).

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
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] Removing 'inst'

2006-01-13 Thread Tim Peters
[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, except for the
inst/WinBuilders/ subdirectory.

(Note that I haven't removed inst/Makefile.win.in on the branch,
because I promised to change only stuff under inst/WinBuilders/ on
that branch.)
___
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: [ZODB-Dev] Re: [Zope-dev] Re: zLOG module deprecated

2006-01-13 Thread Dieter Maurer
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 than the much less informative
   Python tracebacks

  Application code could then use from logging import getLogger
  and use the obtained logger module in the normal way.


-- 
Dieter
___
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] Re: zLOG module deprecated

2006-01-13 Thread Dieter Maurer
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 view

PROBLEM is a synomym for warning. Surely, you want something between
info and error.



-- 
Dieter
___
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] BTreeFolder2.objectIds() - accessing _tree.keys() slow

2006-01-13 Thread sean . upton
 [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 faster.
  I'm still somewhat ignorant as to why self._tree.keys() is so slow 
  with 100k-plus objects (waking up too many persistent objects?),
 
 I suspect the cost is in creating ghosts for all of the 
 persistent objects.
 
 No objections here--I like this patch.

Thanks Shane - glad it makes sense.  I don't have contributor rights - would
you or anyone else be willing to gateway this diff for me and commit such
changes?

Thanks,
Sean
___
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: Removing 'inst'

2006-01-13 Thread Philipp von Weitershausen
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 that's true then I expect
 inst/configure.py is also still useful (it looks like configure.py is
 the intended way to create an actual makefile from the Makefile.in
 template).

Ah, true.

 One thing for sure is that it will be helpful to get rid of as many
 decoys as possible;

+1

I propose moving those two items to the root and remove 'inst'.
 
 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 root of a checkout.
 
 The Windows stuff will have no use for anything other than
 WinBuilders/, so if Makefile.in's Linux purpose would be better served
 by moving that elsewhere, that would be fine.

I don't think it would better or worse be served elsewhere, it's just
that you see Makefile and wonder where it comes from. Looking in 'inst'
isn't obvious at first sight.

The problem I have with configure.py and Makefile.in in 'inst' is that
they're not about installation anymore (which is what 'inst' stands
for). They're about an in-place build. 'WinBuilders' OTOH *is* about
building an installer.

Therefore, just to reduce confusion, I would move Makefile.in and
configure.py to the root (and remove the decoys). I'd also suggest we
rename 'inst' to 'installer' so that it won't be confused with
instance. Then again, this is just me and my weird sense of aesthetics ;).

Philipp
___
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 )