-On [20090329 19:21], Jeffrey Yasskin (jyass...@gmail.com) wrote:
>However, Brett Cannon and I talked, and we think this is surmountable.
>First, nearly every desktop system comes with a Python interpreter, which
>would avoid the bootstrap for ordinary development.
This is quit
Jeffrey Yasskin wrote:
> 1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately
I'm familiar with the Unix and the Windows build system. More than a
year ago I went to a great deal of work to migrate the Windows builds
from VS 7.1 to VS 9.0.
Jeffrey Yasskin:
> 1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately
I have looked at a couple of build tools (scons was probably one)
that generate Visual Studio project files in the past and they
produced fairly poor project files,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to release Python 2.6.2 the week after the conference. I've
talked to a few people here about it and the general consensus is that
we do one brown-paper-bag-avoiding release candidate first. Looking
at the calendar, I propose the foll
David Bolen writes:
>>From what I can see though, the tools/buildbot/test.bat file no longer
> adds the -n option that it used to, although I'm unclear on why it
> might have been removed. Perhaps this was just a regression that was
> accidentally missed, as it appears to have disappeared during
On Sun, Mar 29, 2009 at 1:14 PM, David Cournapeau wrote:
> About cmake: I haven't looked at it recently, but I have a bit of hard
> time believing python requires more from a build system than KDE. The
> lack of autoheader is not accurate, if
> only because kde projects have it:
>
> http://www.cma
On Mon, Mar 30, 2009 at 3:18 AM, Antoine Pitrou wrote:
> What are the compilation requirements for cmake itself? Does it only need a
> standard C compiler and library, or are there other dependencies?
CMake is written in C++. IIRC, that's the only dependency.
cheers,
David
David Cournapeau gmail.com> writes:
>
> I would think the bootstrap problem to be much more significant. I
> don't find the argument "many desktop have already python" very
> convincing - what if you can't install it, for example ?
I agree. I had to build Python once on a corporate AIX box witho
On Mon, Mar 30, 2009 at 2:59 AM, Antoine Pitrou wrote:
> Jeffrey Yasskin gmail.com> writes:
>>
>> The other popular configure+make replacement is scons.
>
> I can only give uninformed information (!) here, but in one company I worked
> with, the main project decided to switch from scons to cmake
Jeffrey Yasskin gmail.com> writes:
>
> The other popular configure+make replacement is scons.
I can only give uninformed information (!) here, but in one company I worked
with, the main project decided to switch from scons to cmake due to some huge
performance problems in scons. This was in 2005
Nice report! Thanks!
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. K
I've heard some good things about cmake — LLVM, googletest, and Boost
are all looking at switching to it — so I wanted to see if we could
simplify our autoconf+makefile system by using it. The biggest wins I
see from going to cmake are:
1. It can autogenerate the Visual Studio project files instea
hi everybody , i am going to do the project on nose compatibility with
core-python testing infrastructure. so i have written the abstract for this
project if someone want
to mentor this project plesae contact me ?
Core Python Testing Infrastructure | Nose
compatibil
On Sun, Mar 29, 2009 at 9:42 AM, Antoine Pitrou wrote:
> There are a couple of ancillary portability concerns due to optimizations
> which
> store system-dependent results of operations between constants in pyc files:
>
> - Issue #5057: code like '\U00012345'[0] is optimized away and its result
Hello,
There are a couple of ancillary portability concerns due to optimizations which
store system-dependent results of operations between constants in pyc files:
- Issue #5057: code like '\U00012345'[0] is optimized away and its result stored
as a constant in the pyc file, but the result should
On Sun, 29 Mar 2009 at 08:35, Gregory P. Smith wrote:
It'd be worthy of fixing in 2.6 since the module exists. Though honestly...
who cares about Irix?
Guido commented on the ticket and closed it, so I closed the other two like it.
--
R. David Murray http://www.bitdance.com
__
On Sun, Mar 29, 2009 at 10:42 PM, "Martin v. Löwis" wrote:
>
>> Maybe I don't understand what is meant by metadata, but I don't
>> understand why we can't provide the same metadata as autotools
>
> Likewise, *this* I do not understand. In what way does autotools
> *provide* metadata? I can underst
Maybe I don't understand what is meant by metadata, but I don't
understand why we can't provide the same metadata as autotools
Likewise, *this* I do not understand. In what way does autotools
*provide* metadata? I can understand that it *uses* certain metadata,
but it doesn't *provide* them...
It'd be worthy of fixing in 2.6 since the module exists. Though honestly...
who cares about Irix?
On Sat, Mar 28, 2009 at 8:53 PM, R. David Murray wrote:
> I'm reviewing http://bugs.python.org/issue2591, which is marked as
> 'security' because it is a potential buffer overflow. almodule.c has
>
Antoine Pitrou writes:
> Lennart Regebro gmail.com> writes:
> >
> > The people who use pythonlibraries are programmers. It can be expected
> > that they are comfortable with the command line.
>
> You probably haven't met lots of Windows (so-called) programmers...
Hey, the "(so-called)" sh
2009/3/29 "Martin v. Löwis" :
>> I think that each OS community should maintain its own tool, that complies
>> to the OS standard (wich has its own evolution cycle)
>>
>> Of course this will be possible as long as Distutils let the system
>> packager find/change the metadata in an easy way.
>
> In
I think that each OS community should maintain its own tool, that complies
to the OS standard (wich has its own evolution cycle)
Of course this will be possible as long as Distutils let the system
packager find/change the metadata in an easy way.
In the specific case of RPMs, I still think that
On 2009-03-25, Guilherme Polo wrote:
> On Tue, Mar 24, 2009 at 4:26 AM, Mark Summerfield
wrote:
> > On 2009-03-23, Guilherme Polo wrote:
> >> On Mon, Mar 23, 2009 at 5:39 PM, Terry Reedy wrote:
> >> > Guilherme Polo wrote:
> >> >> On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy
wrote:
> >> >>> ID
23 matches
Mail list logo
