[Zope-dev] Re: Removing 'inst'
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 )
RE: [Zope-dev] BTreeFolder2.objectIds() - accessing _tree.keys() slow
> [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 )
Re: [Zope-dev] Re: zLOG module deprecated
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] [Zope 2.10] ZPT going Unicode
Tino Wildenhain wrote at 2006-1-13 16:45 +0100: > ... >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 ;)) I fear it is not that easy: Unless we set Python's "defaultencoding" to the site encoding (and we have such a thing), Python cannot mix Unicode and non-Unicode. Thus, your "old" ZPT's would need to use only other old ZPT's and "old" Python scripts and "old" methods (returning encoded texts) while "strict" ZPT's would need to use only new (strict) ZPT's, scripts and methods. Quite unfeasible... -- 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] [Zope 2.10] ZPT going Unicode
Martijn Faassen wrote at 2006-1-13 13:25 +0100: > ... >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. Of course, (textual) input should be converted to Unicode as well. Of course, the encoding used by the browser must be known for this. As the browser usually uses the encoding used by the page containing the form fixing a site encoding might solve this problem. -- 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: [ZODB-Dev] Re: [Zope-dev] Re: zLOG module deprecated
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] Removing 'inst'
[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: [Zope-dev] Removing 'inst'
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'
[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 )
[Zope-dev] Re: Seeking brave souls to try Zope 2.9 Windows installer
[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 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 )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-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] buildbot failure in Zope branches 2.9 2.4 Linux zc-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 )
Re: [Zope-dev] [Zope 2.10] ZPT going Unicode
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 )
Re: [Zope-dev] [Zope 2.10] ZPT going Unicode
--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
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
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 )
[Zope-dev] Zope tests: 8 OK
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 )
[Zope-dev] Removing 'inst'
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 )
