--
http://www.ironpythoninaction.com
On 14 Jul 2009, at 01:12, "Sridhar Ratnakumar"
wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the
Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in
On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé
wrote:
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
Other than easy_install/pip, there is also PyPM which is being
developed at
ActiveState. PyPM is the Python package manager much like what ppm is
for
ActivePerl.
Great ! be
On Mon, Jul 13, 2009 at 2:55 PM, Antoine Pitrou wrote:
>
> Curt Hagenlocher hagenlocher.org> writes:
>>
>> The OS has to provide a mechanism to enable execution for a particular
>> region of memory. Under Windows, this is done by the VirtualProtect
>> function.
>
> More surprising is that Microso
Curt Hagenlocher hagenlocher.org> writes:
>
> The OS has to provide a mechanism to enable execution for a particular
> region of memory. Under Windows, this is done by the VirtualProtect
> function.
More surprising is that Microsoft didn't whitelist their own toolchain.
__
On Mon, Jul 13, 2009 at 2:04 PM, Nick Coghlan wrote:
>
> P.S. I must admit I've never really understood how Data Execution
> Prevention is ever going to work in a world with interpreted languages
> and just in time compilers... the line between data and code is fuzzier
> than one might think for a
2009/7/13 Nick Coghlan :
> Nick Coghlan wrote:
>> For the record, we only have SVN set to force Windows line endings for
>> the old VC6 project files (.dsp and .dsw). The newer versions of Visual
>> Studio can handle Unix line endings just fine so the .sln/.vcprops/etc
>> files are left with native
> I am trying to build Python 3.1 on Windows XP Pro (32 bit) using
> Microsoft Visual C++ Express Edition in order to test some modifications
> I made to the _subprocess.c file as part of my Google Summer of Code
> proposal.
As a posting guideline, please be careful to not post too many messages
Nick Coghlan wrote:
> For the record, we only have SVN set to force Windows line endings for
> the old VC6 project files (.dsp and .dsw). The newer versions of Visual
> Studio can handle Unix line endings just fine so the .sln/.vcprops/etc
> files are left with native line endings and hence end up
Paul Moore wrote:
> 2009/7/13 Eric Pruitt :
>> It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be
>> Unix style but after fixing them, I still have the same problem.
>
> Where did you get your copy of the Python source from? If it's from
> Subversion, I'm surprised the lin
On Fri, 10 Jul 2009 01:56:36 -0700, Paul Moore wrote:
One thing that did occur to me based on this - do we want the format to
support designation of files (such as config files) that *shouldn't* be
uninstalled along with everything else? Or are we happy with not
mentioning the file in RECORD at
Well, I narrowed the culprit down to Windows DEP. I had been having trouble
with it for some time now, with it raising an error for nearly every program
I ran so I just disabled it completely and Python now compiles fine. Thank
you all for the assistance.
On Mon, Jul 13, 2009 at 13:42, Paul Moore
2009/7/13 Paul Moore :
> 2009/7/13 Eric Pruitt :
>> It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be
>> Unix style but after fixing them, I still have the same problem.
[...]
> I'd suggest trying to reproduce your issue with a clean checkout from
> Subversion.
FWIW, I di
The code I downloaded was the official Python 3.1 release tarball. I only
checked the line endings in the pcbuild.sln file so I am not sure about the
other files. I will attempt to build the Python 3000 SVN trunk shortly and
report back.
On Mon, Jul 13, 2009 at 13:09, Paul Moore wrote:
> 2009/7/
2009/7/13 Eric Pruitt :
> It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be
> Unix style but after fixing them, I still have the same problem.
Where did you get your copy of the Python source from? If it's from
Subversion, I'm surprised the line endings are wrong. If it's
On Mon, Jul 13, 2009 at 11:46, Eric Pruitt wrote:
> Hello,
>
> I am trying to build Python 3.1 on Windows XP Pro (32 bit) using Microsoft
> Visual C++ Express Edition in order to test some modifications I made to the
> _subprocess.c file as part of my Google Summer of Code proposal. I cannot
> seem
It is indeed the file ../PCBuild/pcbuild.sln. The line endings appear to be
Unix style but after fixing them, I still have the same problem.
On Mon, Jul 13, 2009 at 11:43, Amaury Forgeot d'Arc wrote:
> 2009/7/13 Eric Pruitt :
> > I opened the solution, hit Ctrl+F5 and it began compiling but it fa
jason pellerin wrote:
Bringing python-dev into the discussion at Barry's request. The
summary is that a recent change to unittest.TestProgram breaks nose by
moving self.testRunner initialization from it's old home in
TestProgram.runTests to TestProgram.__init__. The very small patch
attached to t
I opened the solution, hit Ctrl+F5 and it began compiling but it fails with
this error:
LINK :fatal error LNK1181: cannot open input file '.\python31_d.lib'
How do I specify that "pythoncore" be built? When I follow your
instructions, right clicking on the "python" project in the "Solution
Explore
Sorry, forgot to include my build log:
Command Lines:
http://pastebin.com/f25614b01
Output Window:
> Compiling...
> python.c
> Compiling resources...
> Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
> Copyright (C) Microsoft Corporation. All rights reserved.
> Linking...
> LINK :
Hello,
I am trying to build Python 3.1 on Windows XP Pro (32 bit) using Microsoft
Visual C++ Express Edition in order to test some modifications I made to the
_subprocess.c file as part of my Google Summer of Code proposal. I cannot
seem to figure out how to compile Python on Windows and could use
jason pellerin wrote:
Bringing python-dev into the discussion at Barry's request. The
summary is that a recent change to unittest.TestProgram breaks nose by
moving self.testRunner initialization from it's old home in
TestProgram.runTests to TestProgram.__init__. The very small patch
attached to t
Hi,
2009/7/13 Erik Groeneveld :
> Amaury,
>
> Thank you very much for your detailed explanation. It helps to
> understand it better, and it mostly works now. There is one thing
> however:
>
> On Wed, Jul 8, 2009 at 17:35, Amaury Forgeot d'Arc wrote:
>> - Don't define a JObjectMeta struct, use JO
Amaury,
Thank you very much for your detailed explanation. It helps to
understand it better, and it mostly works now. There is one thing
however:
On Wed, Jul 8, 2009 at 17:35, Amaury Forgeot d'Arc wrote:
> - Don't define a JObjectMeta struct, use JObjectType directly instead.
> An instance of t
24 matches
Mail list logo
