"Martin v. Löwis" writes:
> > How about "-X is reserved for implementation-specific arguments"?
> Isn't that bikeshedding?
No. I think "implementation-specific" is definitely more accurate,
and I was hoping the suggestion might get an immediate "good idea,
implemented", from somebody already
> How about "-X is reserved for implementation-specific arguments"? Ie,
> I suppose that the intent is not that these arguments won't be
> standardized, it's that they be standardized by the affected
> implementations.
Isn't that bikeshedding?
Regards,
Martin
Frank Wierzbicki writes:
> On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > I was also going to suggest a platform independent option. I like
> > -Xwhat-follows-is-impl-dependent.
> This would work just fine for us, and it makes sense to have it
> available for al
On Sat, Apr 12, 2008 at 1:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Great, thanks! While I'd love to have *both* -X and -J, is that okay
> > with the other devs?
>
> +0. If we ever run out of letters for command line options to have
> to collect -J, we have deeper problems than ha
On Sat, Apr 12, 2008 at 11:09 AM, Jeroen Ruigrok van der Werven <
[EMAIL PROTECTED]> wrote:
> I did some more tests concentrating on GCC, partly based on the feedback I
> got, results at
> http://www.in-nomine.org/2008/04/12/python-26-compiler-options-results/
>
> Executive summary: Python needs t
http://bugs.python.org/issue1481036
Basically as things are now EOFError is on its own but often wants to be
handled the same as other I/O errors that EnvironmentError currently covers.
Many uses of EOFError in our code base do not provide it any arguments so it
doesn't really fit the (errno, mes
> Great, thanks! While I'd love to have *both* -X and -J, is that okay
> with the other devs?
+0. If we ever run out of letters for command line options to have
to collect -J, we have deeper problems than having to coordinate
with Jython whether the letter is still available.
Regards,
Martin
___
On Sat, Apr 12, 2008 at 12:39 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
>
> >> -X is reserved for non-standard arguments
> >
> > Fine by me.
>
> And implemented in r62293 (trunk)
Great, thanks! While I'd love to have *both* -X and -J, is that okay
with the other d
I did some more tests concentrating on GCC, partly based on the feedback I
got, results at
http://www.in-nomine.org/2008/04/12/python-26-compiler-options-results/
Executive summary: Python needs to be compiled with -O2 or -O3. Not doing
so, no optimization level, results with GCC 4.2.1 in a doubli
I know this is old stuff, but...
I want to update our Python 2.4 installation at work from 2.4.2 to 2.4.5
(the latest 2.4 source release). I get a test failure for test_pty, an
extra ^M at the end of one line. I don't get a failure in the 2.4.2
installation, but the 2.4.4 and 2.4.5 both fail th
>> #!/bin/sh
>> REPOS="$1"
>> REV="$2"
>> USER="$3"
>> PROPNAME="$4"
>>
>> /data/repos/projects/hooks/mailer.py propchange "$@"
>>
>> The script is the same mailer.py that is also invoked in post-commit.
>> Can anybody see a problem with that?
>
> No, but how many parameters are passed to
Brett Cannon schrieb:
>> -X is reserved for non-standard arguments
>
> Fine by me.
And implemented in r62293 (trunk)
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
On Sat, Apr 12, 2008 at 5:42 AM, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > I was also going to suggest a platform independent option. I like
> > -Xwhat-follows-is-impl-dependent.
> This would work just fine for us
On Sat, Apr 12 2008 at 10:12:18AM BRT, "Daniel (ajax) Diniz" <[EMAIL
PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 12:10 PM, Rodrigo Bernardo Pimentel
> <[EMAIL PROTECTED]> wrote:
> > On Wed, Apr 09 2008 at 11:12:58AM BRT, Trent Nelson <[EMAIL PROTECTED]>
> > wrote:
> > > Hi,
> > >
> > > Is the
On Thu, Apr 10, 2008 at 12:10 PM, Rodrigo Bernardo Pimentel
<[EMAIL PROTECTED]> wrote:
> On Wed, Apr 09 2008 at 11:12:58AM BRT, Trent Nelson <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Is there another online sprint/bugfix day in the pipeline? If not, can
> > there be? ;-)
>
> +1.
>
> The Sao
On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I was also going to suggest a platform independent option. I like
> -Xwhat-follows-is-impl-dependent.
This would work just fine for us, and it makes sense to have it
available for all implementations. If everyone likes th
Jeroen Ruigrok van der Werven wrote:
> Why is CFLAGS in Makefile.pre.in specified as
> CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
> whereas that will negate any CFLAGS you pass to configure?
There is a long history to that. The short version is that configure
decides on its own what flag
Why is CFLAGS in Makefile.pre.in specified as
CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
whereas that will negate any CFLAGS you pass to configure?
A normal call to configure (as ./configure --help also explains) can contain
a CFLAGS specification, e.g.:
CFLAGS="-compiler_options" ./con
-On [20080412 09:32], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote:
>Apparently this section is made by makedepend.
I had no updates for makedepend or autotools, but somewhere along the full
upgrade of all my ports makedepend suddenly started to behave, so some
dependency must h
I do not have this problem on FreeBSD 6.3-STABLE, but on my FreeBSD
7.0-STABLE I get this problem after running an identical ./configure:
[09:11] [EMAIL PROTECTED] (0) {0} % make
"Makefile", line 1192: warning: duplicate script for target "Modules/" ignored
"Makefile", line 1194: warning: duplicat
20 matches
Mail list logo
