Jim Fulton wrote:
When presenting users with ordered text (e.g. sorted lists of options),
simply sorting Unicode strings doesn't provide an ordering that
users in a given locale will find useful. Various languages have
text sorting conventions that don't agree with the ordering of
Unicode
Hi,
Am Freitag, den 09.12.2005, 08:58 -0500 schrieb Jim Fulton:
When presenting users with ordered text (e.g. sorted lists of options),
simply sorting Unicode strings doesn't provide an ordering that
users in a given locale will find useful. Various languages have
text sorting conventions
On Mon, Dec 12, 2005 at 05:40:27AM +0100, Andreas Jung wrote:
The build process changed in 2.9.
Perhaps make inplace; make test should work.
-aj
Good thought, but there is no inplace target anymore.
What is now the canonical way of running tests in a release
tarball? Is there one?
-PW
--
On Mon, Dec 12, 2005 at 07:57:43AM +0100, Tino Wildenhain wrote:
I suspect its the feature which got introduced in 2.8? or so which
has a browser for packets to import so you dont have to
guess and type the name correctly. And to not have to
copy the exaples to every instance home, it
looks
Andreas Jung wrote:
The build process changed in 2.9.
Perhaps make inplace; make test should work.
He explicity said in a tarball. make inplace only exists in SVN. As a
reminder:
SVN repo != release tarball
I know it's always been '==' for every other Zope 2 version, but 2.9 is
different
Paul Winkler wrote:
On Mon, Dec 12, 2005 at 05:40:27AM +0100, Andreas Jung wrote:
The build process changed in 2.9.
Perhaps make inplace; make test should work.
-aj
Good thought, but there is no inplace target anymore.
Yup, Andreas was referring to the SVN checkout.
What is now the
On Mon, Dec 12, 2005 at 04:54:24PM +0100, Philipp von Weitershausen wrote:
Andreas Jung wrote:
The build process changed in 2.9.
Perhaps make inplace; make test should work.
He explicity said in a tarball. make inplace only exists in SVN. As a
reminder:
SVN repo != release tarball
Tino Wildenhain wrote:
Am Sonntag, den 11.12.2005, 23:19 -0500 schrieb Paul Winkler:
Another quickie problem report - no time to investigate further right
now, but can anybody else reproduce? If so, I'll try to fix tomorrow...
In a fresh 2.9.0-b1 instance, made via bin/mkzopeinstance, I get
On Mon, Dec 12, 2005 at 05:01:35PM +0100, Philipp von Weitershausen wrote:
I guess it should use zope.testing.testrunner instead of
zope.app.testing.test, though I'm not sure how the parameters and
options convert.
I don't think that's the problem:
[EMAIL PROTECTED] Zope-2.9-branch $ svn up
On Mon, Dec 12, 2005 at 12:43:35PM -0500, Paul Winkler wrote:
Looks to me like it's a simple PYTHONPATH problem:
(snip)
OK, is Makefile.in the right place to fix that?
This patch seems to work:
[EMAIL PROTECTED] Zope-2.9-branch $ svn diff inst/Makefile.in
Index: inst/Makefile.in
Just to clarify - sorry for confusing the issue (and myself):
There are two separate problems here.
make test doesn't work in a sandbox *or* a release tarball.
The patch below addresses only the former.
Phillip is right about the latter, it's got a broken import.
-PW
On Mon, Dec 12, 2005 at
On Mon, Dec 12, 2005 at 01:08:16PM -0500, Paul Winkler wrote:
Phillip is right about the latter, it's got a broken import.
OK, I have a patch for make test that allows it to at least run,
but with lots of test errors. I think I will have to pass on this
one and leave it to somebody who's more
I'm assuming this is operator error, but I can't make head nor tail of
the following (in a zope 2 trunk sandbox). Note the number of tests run
by each command:
[EMAIL PROTECTED] Zope-Trunk $ python lib/python/OFS/tests/testObjectManager.py
.No handlers could be found for logger Zope
On Mon, Dec 12, 2005 at 03:31:08PM -0500, Paul Winkler wrote:
I'm assuming this is operator error
And so it was. I had SOFTWARE_HOME set pointing to a 2.7 installation!
remembering-to-check-what-crap-is-in-my-environment-next-time-ly-y'rs,
-PW
--
Paul Winkler
http://www.slinkp.com
On Mon, Dec 12, 2005 at 06:05:48PM +0100, Philipp von Weitershausen wrote:
I think supporting $SOFTWARE_HOME/import is yagni and just complicates
things. Let's rip it out.
I'm gonna punt on that: I can imagine hosting providers might be using
that feature already, and I do'nt feel like doing
15 matches
Mail list logo
