Paul Moore wrote:
> Python itself seems to build with no problems at all (there was a
> mention of "Solution folders" not being supported in Express Edition,
> but that doesn't seem to stop anything I need to do to build.
>
> Most of the extensions built fine, and the test suite went through
> wit
On 21/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Paul Moore wrote:
> > > Cool. I'm downloading now, and will report back.
> >
> > How is it going? Does the PCbuild9 directory work with the final version
> > of VS C++ Express?
>
>
Martin v. Löwis wrote:
> That's also an issue - releases typically occur under time pressure,
> trying to get everything done in a single day. If I prepare the
> instrument build in advance, how long can I continue to use the data
> before they get outdated?
Good point! I've chosen PGUpdate over P
> Job for the win64 buildbot, maybe?
Is it possible to share the profile data across machines?
I would certainly want to build and test the releases on
my own machines, rather than having to rely on a buildbot.
I then rather do a multi-reboot thing where I build the AMD64
profiling binaries, reboo
> A word of warning. The PGInstrument builds are *very* slow compared to
> normal builds. The bench mark and test suite need about *TEN* times the
> time to run.
That's also an issue - releases typically occur under time pressure,
trying to get everything done in a single day. If I prepare the
ins
Martin v. Löwis wrote:
> So what's the build process? Is it
>
> 1. start a VS build environment shell
> 2. cd to PCbuild9
> 3. run "build_pgo"
>
> Any additional steps? Should I pass arguments? Can you kindly document
> it in readme.txt?
Yes, you can either use the build_pgo.bat in the PCbuild9
> I've modified the PGO builds and the build_pgo batch file I copied from
> the PCbuild8 directory. For AMD64 builds we either have to buy you an
> AMD64 processor or somebody else has to run the PGI and PGO builds.
So what's the build process? Is it
1. start a VS build environment shell
2. cd to
Boris Borcic wrote:
> FWIW back in march Giovanni Bajo said on mingw-users that GCC-4.x optimized
> his
> code base better than MSVC; that was in
>
> http://article.gmane.org/gmane.comp.gnu.mingw.user/21964/
>
> Now there has been an official "technology preview" release of MingW
> gcc-4.2.1
Gregory P. Smith wrote:
> I would not hold up a compiler decision based on the mingw project.
> Always use the latest MS compiler released at the time for a x.0 build
> of any python. Doing otherwise costs the world a fortune in lost
> performance (higher power consumption via lower efficiency
Christian Heimes schrieb:
> Martin v. Löwis wrote:
>> I would be opposed unless a complete automation of that is possible and
>> can be contributed. For AMD64, I see little hope for that, as I build
>> the releases in a cross-compilation environment, so I can't run them
>> on the build machine.
>
Martin v. Löwis wrote:
> I would be opposed unless a complete automation of that is possible and
> can be contributed. For AMD64, I see little hope for that, as I build
> the releases in a cross-compilation environment, so I can't run them
> on the build machine.
Done ;)
I've modified the PGO buil
> I'd say yes, it should demonstrably produce faster code (easy to test
> that).
I would be opposed unless a complete automation of that is possible and
can be contributed. For AMD64, I see little hope for that, as I build
the releases in a cross-compilation environment, so I can't run them
on t
On 11/21/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
> > I would not hold up a compiler decision based on the mingw project. Always
> > use the latest MS compiler released at the time for a x.0 build of any
> > python. Doing otherwise costs the world a fortune in los
Gregory P. Smith wrote:
> I would not hold up a compiler decision based on the mingw project. Always
> use the latest MS compiler released at the time for a x.0 build of any
> python. Doing otherwise costs the world a fortune in lost performance
> (higher power consumption via lower efficiency co
2007/11/21, Christian Heimes <[EMAIL PROTECTED]>:
> Paul Moore wrote:
> > Cool. I'm downloading now, and will report back.
>
> How is it going? Does the PCbuild9 directory work with the final version
> of VS C++ Express?
Yes, it seems to work. I am currently running the test suite, with
good resul
Martin v. Löwis schrieb:
>> Not that it changes anything, but VS 2008 it was released today.
>
> Actually, it may. I'll see whether I can release 3.0a2 with VS 2008.
> (which depends on whether I can get it through our MSDN subscription,
> and on whether Christian's project files work well enough)
On 11/20/07, Paul Moore <[EMAIL PROTECTED]> wrote:
>
> On 20/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> > PPS I *will* see what the current status of msvcr8/9 support in the
> > Mingw project is, but I'm not too hopeful - mingw is currently
> > undergoing a change of maintainers and progress
> Not that it changes anything, but VS 2008 it was released today.
Actually, it may. I'll see whether I can release 3.0a2 with VS 2008.
(which depends on whether I can get it through our MSDN subscription,
and on whether Christian's project files work well enough)
Regards,
Martin
On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > Cool. I'm downloading now, and will report back.
>
> How is it going? Does the PCbuild9 directory work with the final version
> of VS C++ Express?
I couldn't install at work (don't ask :-() so I'll have to do it at
Paul Moore wrote:
> Cool. I'm downloading now, and will report back.
How is it going? Does the PCbuild9 directory work with the final version
of VS C++ Express?
Christian
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman
On 21/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Not that it changes anything, but VS 2008 it was released today.
> > Cheers,
>
> Nice :)
>
> You can get more information at
> http://msdn2.microsoft.com/en-us/vstudio/products/default.aspx
>
> The express edition is available at
> http
> Not that it changes anything, but VS 2008 it was released today.
> Cheers,
Nice :)
You can get more information at
http://msdn2.microsoft.com/en-us/vstudio/products/default.aspx
The express edition is available at
http://www.microsoft.com/express/download/
Christian
__
Martin v. Löwis wrote:
> Of course, I won't ship any VS 2008 binaries until VS 2008 is released -
> not just because of MingW, but also because the license agreement on
> the VS 2008 betas disallows such releases.
Martin,
Not that it changes anything, but VS 2008 it was released today.
Cheers,
S
Paul Moore wrote:
> I fear that without
> some free toolset being an option in distutils, the level of
> availability of Windows binaries will drop again.
I think it's important that some truly free toolset such as
mingw remains an option. In fact I think it's even more important
than the free MS
On 20/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> [snip]
> > I will help in addressing this issue, but I am limited in my ability
> > to do so, as I cannot build Python itself (that *does* need full VS
> > 2005/2008, as I understand it) and so all I have to go with is
Martin v. Löwis wrote:
> We keep the build files around for a while in the PC subdirectory.
> Sometimes, people contribute patches to keep them working, and as
> long as there are users, I see no reason to drop the build files.
>
> Python should *definitely* continue to compile with older compiler
> I'm not sure but I strongly believe that the express edition is able to
> build 32bit builds of Python. As far as I know the express edition can't
> build PGO and 64bit builds. Please correct me if I'm wrong.
I haven't actually tried, but it may be that you can build 64-bit
binaries if you also
> Whether that counts as an argument for sticking with VS 2005, I don't
> know. I doubt it, realistically. But it *may* constitute an argument
> for not going to VS 2008 until it's actually released
Of course, I won't ship any VS 2008 binaries until VS 2008 is released -
not just because of MingW,
> I'd be happy enough for the diistutils --compiler=mingw option to
> remain the "free" route, but if that means using msvcr71 (because
> mingw doesn't support msvcr 8 or 9)
I think it's a bit to early to claim that mingw doesn't support
mvcr 9 - that library hasn't even been released yet. When it
> If someone already understands the rules for mixing CRT's and has a
> reason to do it then more power to them (I do it at work all the time
> due to toolset limitations). On the other hand, if someone doesn't
> understand the restrictions, then it isn't our (or the c.l.p crowd's)
> job to tea
> I believe Martin has always been the strongest advocate of the "CRT
> must match exactly" position (apologies, Martin, if I've
> misremembered). Maybe he could comment.
See my other comment. For the "unwashed masses", this statement (CRT
must absolutely match), is certainly my recommendation. Fo
> It seems that the restriction that forces you to use the same compiler
> for core python and extension modules does not stand.
>
> Of course, you cannot do everything: for example, FILE* pointers
> cannot be exchanged between different instances of the C runtime.
I wouldn't call that "it works",
> I would strongly advise against going back to the days where a paid MS
> compiler was the only way to build extensions for Windows.
Certainly. If Microsoft follows its recent tradition, they will continue
to publish an "express" version of VS 2008 (and then take the "express"
version of VS 2005
> Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> the default compiler once it has been released, too?
Ah, that. I would certainly hope so - although we may see 3.0a3 first,
as VS 2008 is planned for February.
> In other words: Do we want to support outdated compilers fo
Paul Moore wrote:
[snip]
> I will help in addressing this issue, but I am limited in my ability
> to do so, as I cannot build Python itself (that *does* need full VS
> 2005/2008, as I understand it) and so all I have to go with is the
> snapshot builds (which use VS 2003, and so don't help...)
>
>
> The only question remaining is: do we need the streamreader classes at all.
And if we do, perhaps it simply indicates a limitation of the IO
wrapper classes which should be fixed.
Bill
___
Python-3000 mailing list
Python-3000@python.org
http://mail.py
Guido van Rossum wrote:
> On Nov 19, 2007 3:06 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> Is there anything that you (or anyone else!) would really like to see
>>> added to or fixed in 3.0a2? Now's the time!
>> I am currently having a look at http://bugs.pyth
On 20/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> PPS I *will* see what the current status of msvcr8/9 support in the
> Mingw project is, but I'm not too hopeful - mingw is currently
> undergoing a change of maintainers and progress has slowed a lot.
Apologies. I had an out of date mingw runt
On 20/11/2007, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> If someone already understands the rules for mixing CRT's and has a
> reason to do it then more power to them (I do it at work all the time
> due to toolset limitations). On the other hand, if someone doesn't
> understand the restrictions, th
Paul Moore wrote:
> On 20/11/2007, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
>> Am I missing something? Should we lift the restrictions we impose on
>> compilers of extension modules? Can we carefully design the Python API
>> to accept different compilers/runtime?
>
> I have done similar exp
On 20/11/2007, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Am I missing something? Should we lift the restrictions we impose on
> compilers of extension modules? Can we carefully design the Python API
> to accept different compilers/runtime?
I have done similar experiments in the past. There
Paul Moore wrote:
> On 20/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> > the default compiler once it has been released, too?
> >
> > In other words: Do we want to support outdated compilers for legacy
> > reasons
On 20/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> the default compiler once it has been released, too?
>
> In other words: Do we want to support outdated compilers for legacy
> reasons or can we stick to 2005 as th
Martin v. Löwis wrote:
>> We should also start to discuss how to address some Windows problems.
>> Amaury has brought up some important points and I like to get some
>> feedback on the default compiler topic. Are we going to drop VS 2003
>> after the 3.0a2 release and use VS 2008 as the default com
> We should also start to discuss how to address some Windows problems.
> Amaury has brought up some important points and I like to get some
> feedback on the default compiler topic. Are we going to drop VS 2003
> after the 3.0a2 release and use VS 2008 as the default compiler?
We cannot use that
On Nov 19, 2007 3:58 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Is there anything that you (or anyone else!) would really like to see
> > added to or fixed in 3.0a2? Now's the time!
>
> I like to have the bugs w/o priority or high and important priority
> reviewed
Guido van Rossum wrote:
> Is there anything that you (or anyone else!) would really like to see
> added to or fixed in 3.0a2? Now's the time!
I like to have the bugs w/o priority or high and important priority
reviewed before we release 3.0a2.
http://bugs.python.org/[EMAIL
PROTECTED],id,activity
On Nov 19, 2007 3:06 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Is there anything that you (or anyone else!) would really like to see
> > added to or fixed in 3.0a2? Now's the time!
>
> I am currently having a look at http://bugs.python.org/issue1460 .
> It's
Guido van Rossum wrote:
> Is there anything that you (or anyone else!) would really like to see
> added to or fixed in 3.0a2? Now's the time!
I am currently having a look at http://bugs.python.org/issue1460 .
It's a problem in the utf-7 decoder (there is no such function
PyUnicode_DecodeUTF7Statef
On Nov 19, 2007 12:47 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Do you have a schedule for the release of the next alpha? If I recall
> correctly the alpha 2 is planed for end of November.
Indeed. I think we can still make that goal; there isn't anything big
that I really want in the relea
Hi Guido!
Do you have a schedule for the release of the next alpha? If I recall
correctly the alpha 2 is planed for end of November.
Christian
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubs
51 matches
Mail list logo
