Martin v. Löwis writes:
It seems that both Dirkjan and Brett are very caught up
with real life for the coming months. So I suggest that
some other committer who favors the Mercurial transition
steps forward and takes over this project.
I am not a committer, and am not intimately familiar
Am 30.06.2010 07:37, schrieb Martin v. Löwis:
It seems that both Dirkjan and Brett are very caught up
with real life for the coming months. So I suggest that
some other committer who favors the Mercurial transition
steps forward and takes over this project.
If nobody volunteers, I propose
Guido van Rossum guido at python.org writes:
As for protocol buffers, assuming its absence (so far from the
stdlib is the only objection, how hard would it be to make the logging
package prepared so that if one *did* have protocol buffers
installed, it would be a one-line config setting to
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hence it cannot open /dev/tty. If you are curious,
just patch your checkout to output the exact
R. David Murray wrote:
On Tue, 29 Jun 2010 17:02:14 -0400, Steve Holden st...@holdenweb.com wrote:
Guido van Rossum wrote:
- wrap the binary stream in a text stream
wrap how? The ultimate destiny of the text is twofold:
I would imagine Guido is talking about an io.TextIOWrapper...in other
Guido van Rossum gu...@python.org wrote:
On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen jans...@parc.com wrote:
My Leopard and Tiger PPC buildbots are momentarily green! But I'm
looking into why I'm skipping some tests. My buildbots are up-to-date
OS-wise and very vanilla, with the latest
Martin v. Löwis mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before?
Possibly, but I don't recall doing so.
The buildbot slave has no controlling
terminal anymore, hence it cannot open /dev/tty. If you are curious,
exar...@twistedmatrix.com wrote:
Could the test be rewritten (or supplemented) to use a pty? Most or
perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make buildbottest
in dir
On Tue, 29 Jun 2010 20:05:29 -0400
R. David Murray rdmur...@bitdance.com wrote:
I would imagine Guido is talking about an io.TextIOWrapper...in other
words, take the binary file you've just finished grabbing info
from, and reread it as a text file in order to grab the actual
message content.
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen jans...@parc.com wrote:
So, my question then is, why are these skips unexpected? Seems to me
that if this is the case, this test will never run on any platform.
You can change the value of the usepty option in your buildbot.tac.
(you will also
On Wed, Jun 30, 2010 at 9:42 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 29 Jun 2010 20:05:29 -0400
R. David Murray rdmur...@bitdance.com wrote:
I would imagine Guido is talking about an io.TextIOWrapper...in other
words, take the binary file you've just finished grabbing info
On Wed, 30 Jun 2010 10:03:49 -0700
Guido van Rossum gu...@python.org wrote:
Also, please note that values used by seek() and tell() on
text I/O are opaque cookies. While they can happen to match the
raw binary file position, it is a mere coincidence (or an
implementation detail, at your
On Wed, Jun 30, 2010 at 10:20 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 10:03:49 -0700
Guido van Rossum gu...@python.org wrote:
Also, please note that values used by seek() and tell() on
text I/O are opaque cookies. While they can happen to match the
raw binary
Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com:
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hence it cannot open /dev/tty. If you are
I'm trying to catch up on this thread, so I may collapse some responses or
refer to points others have brought up.
On Jun 24, 2010, at 05:53 PM, Scott Dial wrote:
If the package has .so files that aren't compatible with other version
of python, then what is the motivation for placing that in a
On Jun 26, 2010, at 10:22 PM, Matthias Klose wrote:
On 24.06.2010 22:46, Barry Warsaw wrote:
So, we could say that PEP 384 compliant extension modules would get written
without a version specifier. IOW, we'd treat foo.so as using the ABI. It
would then be up to the Python runtime to throw
On Jun 25, 2010, at 04:53 AM, Scott Dial wrote:
My suggestion was that a package that contains .so files should not be
shared (e.g., the entire lxml package should be placed in a
version-specific path).
Matthias outlined some of the pitfalls with this approach.
The motivation for this PEP was
On 04:44 pm, solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen jans...@parc.com wrote:
So, my question then is, why are these skips unexpected? Seems to
me
that if this is the case, this test will never run on any platform.
You can change the value of the usepty
On 04:26 pm, jans...@parc.com wrote:
exar...@twistedmatrix.com wrote:
Could the test be rewritten (or supplemented) to use a pty? Most or
perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make
On Jun 26, 2010, at 06:50 PM, Scott Dial wrote:
On 6/26/2010 4:06 PM, Matthias Klose wrote:
On 25.06.2010 22:12, James Y Knight wrote:
On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
Placing .so files together does not simplify that install process in any
way. You will still have to handle
On Jun 25, 2010, at 11:58 AM, Brett Cannon wrote:
Placing .so files together does not simplify that install process in any
way. You will still have to handle such packages in a special way. You
must still compile the package multiple times for each relevant version
of python (with special
On Jun 25, 2010, at 03:42 PM, Scott Dial wrote:
On 6/25/2010 2:58 PM, Brett Cannon wrote:
I assume you are talking about PEP 3147. You're right that the PEP was
for pyc files and that's it. No one is talking about rewriting the
PEP.
Yes, I am making reference to PEP 3147. I make reference to
On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
Scott Dial wrote:
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
If you want to make it so a system can install a package in just one
location to be used by multiple Python installations, then the version
number
On 05:29 pm, mar...@v.loewis.de wrote:
Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com:
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore,
On 06:46 pm, exar...@twistedmatrix.com wrote:
On 04:44 pm, solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen jans...@parc.com wrote:
So, my question then is, why are these skips unexpected? Seems to
me
that if this is the case, this test will never run on any
On Wed, Jun 30, 2010 at 09:03, Bill Janssen jans...@parc.com wrote:
Martin v. Löwis mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before?
Possibly, but I don't recall doing so.
The buildbot slave has no controlling
The whole unexpected skipping is somewhat of a mess. In an ideal
situation modules that are optionally built should be allowed to skip,
While this may be the wide-spread interpretation, it is definitely *not*
the original intention of the feature.
When Tim Peters added it, he wanted it to tell
Martin v. Löwis mar...@v.loewis.de wrote:
The whole unexpected skipping is somewhat of a mess. In an ideal
situation modules that are optionally built should be allowed to skip,
While this may be the wide-spread interpretation, it is definitely *not*
the original intention of the feature.
Barry Warsaw wrote:
On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
Scott Dial wrote:
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
If you want to make it so a system can install a package in just one
location to be used by multiple Python installations,
On Wed, Jun 30, 2010 at 12:53, Martin v. Löwis mar...@v.loewis.de wrote:
The whole unexpected skipping is somewhat of a mess. In an ideal
situation modules that are optionally built should be allowed to skip,
While this may be the wide-spread interpretation, it is definitely *not*
the
On Thu, Jul 1, 2010 at 5:53 AM, Martin v. Löwis mar...@v.loewis.de wrote:
When Tim Peters added it, he wanted it to tell him whether he did the
Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
possibly work on Windows. If you try to generalize this beyond Windows,
then the
On Wed, Jun 30, 2010 at 14:52, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:53 AM, Martin v. Löwis mar...@v.loewis.de wrote:
When Tim Peters added it, he wanted it to tell him whether he did the
Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
possibly work
When Tim Peters added it, he wanted it to tell him whether he did the
Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
possibly work on Windows. If you try to generalize this beyond Windows,
then the only skips that are expected are the ones for tests that
absolutely cannot
On Wed, Jun 30, 2010 at 15:01, Martin v. Löwis mar...@v.loewis.de wrote:
When Tim Peters added it, he wanted it to tell him whether he did the
Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
possibly work on Windows. If you try to generalize this beyond Windows,
then the only
On Jun 30, 2010, at 10:35 PM, M.-A. Lemburg wrote:
The Python default installation dir for
libs (including site-packages) is $prefix/lib/pythonX.X, so you
already have separate and properly versioned directory paths.
What difference would the extra version on the .so file make in
such a setup ?
On Thu, Jul 1, 2010 at 7:55 AM, Brett Cannon br...@python.org wrote:
So it isn't that it's unexpected, it's that a dependency is missing.
So it seems the terminology needs to get tweaked.
More that the phrase expected skip isn't clearly defined and people
sometimes guess wrong as to what it
On Jul 01, 2010, at 07:52 AM, Nick Coghlan wrote:
Note that it works this way on Linux as well. On Kubuntu (for example)
you need another half dozen or so additional *-dev packages installed
to avoid unexpected test skips.
Cheers,
Nick.
P.S. For anyone curious, I posted the list of extra
On Wed, Jun 30, 2010 at 15:20, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 7:55 AM, Brett Cannon br...@python.org wrote:
So it isn't that it's unexpected, it's that a dependency is missing.
So it seems the terminology needs to get tweaked.
More that the phrase expected skip
Brett Cannon wrote:
On Wed, Jun 30, 2010 at 15:01, Martin v. Löwis mar...@v.loewis.de
wrote:
When Tim Peters added it, he wanted it to tell him whether he
did the Windows build correctly, INCLUDING ALL OPTIONAL
PACKAGES that can possibly work on Windows. If you try to
generalize this beyond
/me throws hat into ring. I'm in the middle of migrating fairly
large chunks of an overgrown codebase from Subversion to Mercurial,
so I might actually have worthwhile input :)
--
~Dan
On Wed, Jun 30, 2010 at 10:41:51AM +0200, Georg Brandl wrote:
Am 30.06.2010 07:37, schrieb Martin v. Löwis:
Hi,
I would like to modify the code of the bdist installers, but I don't
see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
thanks,
David
___
Python-Dev mailing list
Python-Dev@python.org
I would like to modify the code of the bdist installers, but I don't
see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
See PC/bdist_wininst.
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Am 01.07.2010 02:01, schrieb Dan Buch:
/me throws hat into ring. I'm in the middle of migrating fairly
large chunks of an overgrown codebase from Subversion to Mercurial,
so I might actually have worthwhile input :)
To all the volunteers: an issue that apparently requires immediate
attention
On Thu, Jul 1, 2010 at 1:22 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I would like to modify the code of the bdist installers, but I don't
see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
See PC/bdist_wininst.
Hm, my question may not have been clear: *how* is the
See PC/bdist_wininst.
Hm, my question may not have been clear: *how* is the wininst-9.0
built from the bdist_wininst sources ? I see 6, 7.0, 7.1 and 8.0
versions of the visual studio build scripts, but nothing for VS 9.0.
Ah. See PCbuild/bdist_wininst.vcproj.
Regards,
Martin
[Barry Warsaw]
As an aside, I wonder if it would make sense to create an Ubuntu/Debian
package that essentially just depended on all those -dev packages. That way
you could install this python-uber-dev package and get everything you needed
to build a sumo Python.
I don’t know. Any Debian
46 matches
Mail list logo
